* speed up from/to screen conversion of BRects and BRegions
* invisible views don't need updating
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16257 a95241bf-73f2-0310-859d-f6bbb57e9c96
in all drawing methods in case the parent window was
not in a "transaction" (fInTransaction). For ordinary
updates, nothing has changed, but if you call drawing
methods outside of an update, they will happen "immediately"
rather than when the link is sporadically full and auto
flushes. The effect is that the cursor in Terminal blinks
reliably, the selection in BTextViews follows the mouse
right on the spot (and so on). BWindow::BeginViewTransaction()
and EndViewTransaction() now have a meaning in Haiku too.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15927 a95241bf-73f2-0310-859d-f6bbb57e9c96
was not such a bad idea after all.
* Reenabled obscuring the cursor in ServerApp.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15925 a95241bf-73f2-0310-859d-f6bbb57e9c96
it's Activate() method is called, if there is no
new focus app, the cursor is unhidden for safety. The
most notable difference: After having run a screen
saver, the cursor will be visible again.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15919 a95241bf-73f2-0310-859d-f6bbb57e9c96
* reworded Activate and commented out all code
that actually tries to change the cusor shape
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15917 a95241bf-73f2-0310-859d-f6bbb57e9c96
partly, fDisplayBitmap is not correctly re-established...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15887 a95241bf-73f2-0310-859d-f6bbb57e9c96
(TODO: do this after a time out)
* quick hack to display bitmaps containing an
alpha channel with a checker background
(TODO: rework filters to be alpha channel
aware and compose the checker background
independently of the filter)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15886 a95241bf-73f2-0310-859d-f6bbb57e9c96
* 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
* make sure layers are removed from the token space when the
WindowLayer is deleted
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15852 a95241bf-73f2-0310-859d-f6bbb57e9c96
* BViews set fOwner to NULL recursively when detached
* updated a comment
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15851 a95241bf-73f2-0310-859d-f6bbb57e9c96
now run under BeOS as well (as long as they don't use any functions that are not
available under R5).
The solution is a bit messy, but we have to live with it :-)
The runtime loader now patches the __gRuntimeLoader symbol in libroot.so to point
to its exported structure instead of passing it to the init functions as an
argument.
(Hax0red by axeld and bonefish on stippi's assimilated machine -- resistence is futile)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15848 a95241bf-73f2-0310-859d-f6bbb57e9c96
a mix of the liblayout look (I hope Marcus doesn't mind)
and BMenuFields. I will have to clean up after myself one
day and calculate the tab rects properly instead of drawing
far out of the right side of tabs and adding a weird offset
to the label rendering and other places...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15801 a95241bf-73f2-0310-859d-f6bbb57e9c96
-> fixes some clipping problems (because of
hinting, the text was displayed at a rounded
position anyways, but the clipping calculation
was screwed up)
* take the drawing_mode and low color from the
current state for drawing line arrays
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15800 a95241bf-73f2-0310-859d-f6bbb57e9c96
* added another optimized bitmap drawing routine
for B_OP_ALPHA and BGR[A]32 bitmaps. When actual
blending takes place, it is more than 1.7 times
faster than R5, and about the same speed when
the bitmap is fully opaque.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15761 a95241bf-73f2-0310-859d-f6bbb57e9c96
with quite good results I might add. Drawing B_RGB32
bitmaps is more than 1.2 times faster than on R5, while
B_CMAP8 bitmaps are slightly slower. The optimization
is only for B_OP_COPY and unscaled bitmaps
(B_RGB32 and B_CMAP8). Drawing only parts of the bitmap
is supported. Adding optimization for scaled bitmaps
should be beneficial, since the generic version is 2 two
4 times slower. I think it gets even worse for partial
bitmaps.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15758 a95241bf-73f2-0310-859d-f6bbb57e9c96
and ResizeBy()
* WindowLayer::SetSizeLimits() needs to be called with the
AllWindows lock held
* I was observing weird behaviour with "unclickable" windows
that I might have fixed by explicitly excluding invisible
windows from Desktop::WindowAt(), there might be something
wrong with the "current" window list though, Axel would know
* finally found the problem with "delayed background clearing"
* enabled delayed background clearing and removed unnecessary
code. It should be more efficient, since it clears larger
areas at once, and it solves the problem of views unable to
draw into regions that are pending for another update - among
other things, updates in resizing windows are more fluent,
especially for B_FULL_UPDATE_ON_RESIZE views. "Cut off" scroll
bars should no longer appear when the view being scrolled takes
too long to redraw.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15714 a95241bf-73f2-0310-859d-f6bbb57e9c96
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
using the clipping info from a BDirectWindow... I made it so that the window
used stays on top always, until I can think of something better. The other
problem is that you should not move the window, since Painter doesn't update
it's pointer into the frame buffer.
* Now the test environment is running at pretty much the same speed as it would
under Haiku, completely by-passing the BeOS app_server. It shows that Painter
needs to be optimized for writing to graphics memory, and also that we need to
figure out a way to distribute update sessions more equally. What happens is
this: The first invalidation of a window triggers an update on the client
side... the client cannot keep up with drawing, since it is pretty much
blocked all the time because the desktop thread moves a window and because
the clipping constantly changes. In the meantime, new update request are
added to the pending session because the client has still not finished with
the current session. Only when things settle a bit, the next update session
can be startet. On the bright side of things, the earlier problems with
scrolling seem to be fixed for good.
* some documentation updates on Painter
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15478 a95241bf-73f2-0310-859d-f6bbb57e9c96
* finally nailed that much hated bug where the
wrong background underneath the cursor was restored.
I always looked for this in the wrong place -
of course, you cannot blit regions on top
of the cursor and expect the backup of the
background to be magically valid still... ;-)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15461 a95241bf-73f2-0310-859d-f6bbb57e9c96
to avoid any confusion with MarkContentDirty()
* hopyfully fixed all drawing defects that could be
observed with CopyBits()ing and ScrollTo()ing, the fix
is definitely valid, and I cannot see any more problems
in Tracker either... hopefully this is it.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15458 a95241bf-73f2-0310-859d-f6bbb57e9c96
* prevents the target view from being scrolled out of range
* handles Trackers completely confused usage of scrollbars
There is just one problem with Tracker's horizontal scrollbar
scrolling the title view much further than it should, which I
will look into tomorrow...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15457 a95241bf-73f2-0310-859d-f6bbb57e9c96
Stephan Aßmus