* Menu windows now use the kMenuWindowFeel feel (but still need the B_AVOID_FOCUS
flag set, as that's currently independent from the feel).
* Minor cleanup in MenuWindow.cpp
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16150 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
as well now, and makes quite a difference in Qemu.
Not tested for standard BViews, though.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15907 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
Might reveal other problems in this area, that are worth looking into.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15823 a95241bf-73f2-0310-859d-f6bbb57e9c96
on workspace 1 just because the system booted in that workspace? :-)
Now modal windows are opened on the current workspace.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15813 a95241bf-73f2-0310-859d-f6bbb57e9c96
though (ideally when launched).
* B_MODAL_APP_WINDOW_FEEL windows are now visible on the initial app workspace
in case it has no other window visible. This fixes the missing BAlerts in
the debug_server or just the "alert" command. Thanks to Stephan for pointing
this out.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15811 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
with the "EventMask" test app the last time:
* The focus view didn't get any mouse messages anymore if there was a permanent
B_POINTER_EVENTS view.
* B_KEYBOARD_EVENTS now works again.
* B_MOUSE_WHEEL_CHANGED messages no do arrive their targets without prior
keyboard input.
* Added TODO item that other focus messages don't go through to the app without
keyboard input (fix only works for B_MOUSE_WHEEL_CHANGED).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15754 a95241bf-73f2-0310-859d-f6bbb57e9c96
it could crashed the server.
* ViewLayer now deletes the view bitmap on destruction, if any.
* BitmapManager::Delete() now also accepts NULL bitmaps.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15723 a95241bf-73f2-0310-859d-f6bbb57e9c96
or even the resizing mode isn't done yet, though. See TODOs.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15720 a95241bf-73f2-0310-859d-f6bbb57e9c96
as only the BitmapManager class is allowed to call them.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15718 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
mappings yet, that's a good way to test this functionality.
* Turns out the directory of the mappings must be known already - they
should be added automatically, but I've added them manually for now
(which is okay for the default system directory).
* Having more than one style with the same family in the mappings didn't
work as planned - it now does.
* On my current system, time spend in the font manager constructor went
down from 1.5 secs to around 12000 usecs (and I have only a moderate
number of fonts installed, or so I thought - looks like the mappings
were a good idea :-)) - and that directly cuts down the boot time.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15580 a95241bf-73f2-0310-859d-f6bbb57e9c96
the debugger - killing them only very rarely works out anyway.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15516 a95241bf-73f2-0310-859d-f6bbb57e9c96
the AS_REDRAW message.
The AS_REDRAW message is now only used as a notifier - it's arrival is not
critical anymore, IOW it's simply dropped when the queue is full.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15511 a95241bf-73f2-0310-859d-f6bbb57e9c96
It also fixed a bug in the old code - the handshake semaphores were created
acquirable, causing the BDirectWindow::DirectDaemonFunc() to call DirectConnected()
with an uninitialized buffer and way too early - this probably didn't show up
before since it called it before the BDirectWindow constructor ran through,
so that DirectConnected() would still point to the BDirectWindow version, and
not to the implemented one of its subclass...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15505 a95241bf-73f2-0310-859d-f6bbb57e9c96
app_server...
If you like to use it, define USE_DIRECT_WINDOW_TEST_MODE in the haiku_app_server
Jamfile.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15504 a95241bf-73f2-0310-859d-f6bbb57e9c96
