Reverted accidental commit.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33485 a95241bf-73f2-0310-859d-f6bbb57e9c96

Work in progress of moving the (audo-)mounting functionality from Tracker into
a dedicated mount server. This is pretty much a straight copy from the
AutoMounter code from Tracker, except
* the eject

Work in progress of moving the (audo-)mounting functionality from Tracker into
a dedicated mount server. This is pretty much a straight copy from the
AutoMounter code from Tracker, except
* the eject on unmount setting has been added (in Tracker, it's part of the
general settings, not the mount specific ones),
* scripting features have been added, such that it becomes possible to trigger
mounting the previoulsy mounted volumes from the outside, and most
importantly block until the operation is done (waiting for the reply).

TODO:
* Change Tracker to not run it's own AutoMounter, but send messages to the
new server.
* Move the eject when unmounting setting to the mount settings window.
* Enable the mount_server in the Bootscript.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33484 a95241bf-73f2-0310-859d-f6bbb57e9c96

show more ...

patch by Andrej Spielmann (GSOC):
* Added marco definitions for subpixel based blending of two 32 bit pixels.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26354 a95241bf-73f2-0310-859d-f6bbb

patch by Andrej Spielmann (GSOC):
* Added marco definitions for subpixel based blending of two 32 bit pixels.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26354 a95241bf-73f2-0310-859d-f6bbb57e9c96

show more ...

* All drawing modes except for B_OP_COPY should respect transparent pixels in
source bitmaps. The destination is preserved now when encountering such
transparent pixels in the source bitmaps.
* B

* All drawing modes except for B_OP_COPY should respect transparent pixels in
source bitmaps. The destination is preserved now when encountering such
transparent pixels in the source bitmaps.
* B_OP_ERASE is supposed to replace with the low color whereever a source
bitmap has a non-transparent pixel.
* The B_OP_MIN and B_OP_MAX drawing modes are supposed to select either the
source or destination pixel based on their brightness, not combine the two
pixels' color components into a new pixel. The brightness_for() function is
taken from ColorConversion.cpp in the interface kit. Probably a simpler
algorithm would do as well.
* Handle B_TRANSPARENT_MAGIC_* in all cases when drawing bitmaps with non-alpha
source bitmaps, as all modes except B_OP_COPY are sensitive to transparency.

This should make all drawing modes behave as documented in the BeBook. Except
for B_OP_SELECT, which seems broken under R5, the results compare nicely now.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26075 a95241bf-73f2-0310-859d-f6bbb57e9c96

show more ...

* don't read the frame buffer a second time when no
blending has to take place


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18839 a95241bf-73f2-0310-859d-f6bbb57e9c96

* implemented view bitmap options (B_BITMAP_TILE...) in
ViewLayer (for example, fixes NetPositive rendering
HTML with a background image)
* use BRegion pool everywhere in ViewLayer
* WindowLayer

* implemented view bitmap options (B_BITMAP_TILE...) in
ViewLayer (for example, fixes NetPositive rendering
HTML with a background image)
* use BRegion pool everywhere in ViewLayer
* WindowLayer update sessions distinguish between
different reasons for the update: exposed and requested -
on expose updates, the view backgrounds are cleared
immidiately (as on R5), to keep the time previous stuff
keeps showing as short as possible, while on requested
updates, the background clearing is delayed until the
client draws something, to keep the time until the client
fills a view with content as small as possible to reduce
flickering (might need more work, could be buggy yet)
* HWInterface and DrawingEngine support delayed syncing to
the graphics hardware at least for FillRect/Region. The
speed up gained by this is minor though.
* HWInterface cursor rendering uses a bit of rounding to
avoid the slight transparent shadow around the cursor
(I don't know if it is fully correct though, at least the
shasow disappeared)


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17172 a95241bf-73f2-0310-859d-f6bbb57e9c96

show more ...

ServerFont:
* fixed weird pointer conversion in SetStyle()
* fixed a potential mix up in operator=() in case the
other ServerFont has fStyle == NULL

ServerWindow:
* the WindowLayer fTopLayer canno

ServerFont:
* fixed weird pointer conversion in SetStyle()
* fixed a potential mix up in operator=() in case the
other ServerFont has fStyle == NULL

ServerWindow:
* the WindowLayer fTopLayer cannot be deleted by
client request, just for safety reasons
* the link is flushed if there is no drawing engine,
but this case is theoretical only
* deleting the ServerWindow object syncs with the
client, so that when BBitmaps are deleted, they
can be sure there are no pending messages (which
would be executed in a nother thread)
* there is no timeout anymore when sending messages
to the client, which made absolutely no sense

AGGTextRenderer:
* renamed fFontManager to fFontCache, because that's
what it really is
* fLastFamilyAndStyle defaulted to the system plain
font and therefor that font was never loaded when
the font never changed meanwhile

DrawingMode:
* I'm not quite sure but I think there was the
potential of a division by zero, at least I
had crashes with "divide error"

HWInterface:
* fix update when the cursor shape changed in
double buffered mode

ViewLayer:
* since the top layer is never really deleted
before its time has come, it is not necessary
to set it to NULL in the ViewLayer destructor

ViewLayer/WindowLayer:
* added a function to collect the view tokens
that are affected by an update session

EventDispatcher:
* use the importance of the message for the timeout
in _SendMessage()
* drop mouse moved events in the server if we're
lagging behind more than 5 ms (Axel, maybe review)

View:
* there were some problems with the locking
of the BWindow looper in RemoveSelf(), since
this is called from the window destructor,
also of BWindows from BBitmaps, which have
never been run (this might need review), at
least I seem to have solved the crashing
problems introduced by actually deleting the
view hirarchy in the BWindow destructor
* fixed _Draw() for being used non-recursively,
temporarily disabled DrawAfterChildren, which
didn't work yet anyways (because views cannot
draw over children in the server yet)

Window:
* small cleanup when deleting shortcuts
* sync with the server when having send
AS_DELETE_WINDOW (see ServerWindow above)
* fixed locking in Begin/EndViewTransaction()
* removed folding of _UPDATE_ messages, since
there is only one ever in the queue
* set the fInTransaction flag during an update,
I plan to use this in BView later to
flush the link when drawing outside of an
update
* BView::_Draw() is now called by view token,
this gives the next leap forward in speed,
the overhead because of drawing clean views
was considerable



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15878 a95241bf-73f2-0310-859d-f6bbb57e9c96

show more ...

* extracted the frame buffer memcpy routine from HWInterface.cpp
into a new frame_buffer_support.h
* added blend32 routine for blending a certain color with
a scanline in the frame buffer
* added

* extracted the frame buffer memcpy routine from HWInterface.cpp
into a new frame_buffer_support.h
* added blend32 routine for blending a certain color with
a scanline in the frame buffer
* added "solid" versions of B_OP_ALPHA drawing with
B_ALPHA_OVERLAY alha function (blending on top of
a non-transparent background such as the frame buffer)
* implemented an optimized shortcut for alpha blended
FillRect() in Painter
* used the "packed" version of scanlines for shapes with
an outline thicker than 4 pixels (and filled shapes anyways),
this improves drawing speed when there are a few anti-aliased
pixels at the beginning of a scanline, then a solid fill and
some anti-aliased pixels at the end of the scanline. Such as
large letters.

To summarize: The alpha blending in Painter seems to be about
1.45 times faster than on BeOS R5 which benefits drawing large
shapes. For example, drawing a large alpha blended rounded rect
is 1.28 times faster on the Haiku app_server. On the other hand,
B_OP_COPY is quite tough to beat. It is currently 10 times faster
on R5. But a great deal seems to be caused by the Painter
rasterization algorithm itself, since commenting out the actual
drawing doesn't gain any speed.
The other useful experience I collected was that reading and
writing and over the PCI bus in the same loop really hurts
performance. It is actually faster (like 1.8 times!!) to allocate
a second buffer, read from frame buffer into that, doing the
blending at the same time, then writing the buffer back to the
screen.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15698 a95241bf-73f2-0310-859d-f6bbb57e9c96

show more ...

first simplistic implementation of drag bitmaps, drawing modes need more work, drawing text into offscreen bitmaps seems to be broken for some weird reason, B_OP_COPY actually copies the alpha value

first simplistic implementation of drag bitmaps, drawing modes need more work, drawing text into offscreen bitmaps seems to be broken for some weird reason, B_OP_COPY actually copies the alpha value of the color as well

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15671 a95241bf-73f2-0310-859d-f6bbb57e9c96

show more ...

complete rework of the drawing_modes implementation... I achieved a speedup of 8 to 9 times, tested with text rendering. Believe it or not, but the Haiku text rendering is now faster than R5 for B_OP

complete rework of the drawing_modes implementation... I achieved a speedup of 8 to 9 times, tested with text rendering. Believe it or not, but the Haiku text rendering is now faster than R5 for B_OP_COPY at least. And there is quite some room for improvement yet. (faster text bounding box calculation, avoiding the double UTF8 conversion, etc)

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15596 a95241bf-73f2-0310-859d-f6bbb57e9c96

show more ...

now has a special version of B_OP_OVER for solid patterns as well, accelerated the alpha blending for B_OP_OVER.... these are the first shy steps of rewriting the drawing mode stuff... :-)

git-svn-i

now has a special version of B_OP_OVER for solid patterns as well, accelerated the alpha blending for B_OP_OVER.... these are the first shy steps of rewriting the drawing mode stuff... :-)

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15532 a95241bf-73f2-0310-859d-f6bbb57e9c96

show more ...

added license headers

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12817 a95241bf-73f2-0310-859d-f6bbb57e9c96

more correct implementation of B_OP_COPY, in that it blends against the current low color (as seen in text rendering on BeOS), of course this extends to anti-aliased lines on Haiku

git-svn-id: file:

more correct implementation of B_OP_COPY, in that it blends against the current low color (as seen in text rendering on BeOS), of course this extends to anti-aliased lines on Haiku

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12559 a95241bf-73f2-0310-859d-f6bbb57e9c96

show more ...

I'm not sure this is needed, because inherited DrawingModes don't have any data and do nothing in their constructor, but I'll rather be on the safe side

git-svn-id: file:///srv/svn/repos/haiku/haiku

I'm not sure this is needed, because inherited DrawingModes don't have any data and do nothing in their constructor, but I'll rather be on the safe side

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12414 a95241bf-73f2-0310-859d-f6bbb57e9c96

show more ...

moved Painter into drawing

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@11989 a95241bf-73f2-0310-859d-f6bbb57e9c96