a string
* fixed profiling of message processsing in ServerWindow (didn't take batch
processing into account)
* accelerated ViewLayer::RebuildClipping() by a factor of two by avoiding
BRegion::Exclude(clipping_rect) for each child, and instead building
one region with all children, and excluding that. RebuildClipping() is
quite a common operation and is quite slow for views with many children
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21646 a95241bf-73f2-0310-859d-f6bbb57e9c96
not need to be "set" (transfered from the "current" view to the painter)
for each singly drawing command. Now, painter is synchronized whenever
the client changes the drawing state of the current view, or when the
current view changes.
* the screen offset of the current view has become part of the Painter state,
in the PatternHandler. This fixes a bug in which moving or scrolling a view
which used patterns for drawing, resulted in visual glitches (seams in the
pattern).
NOTE: this patch is a bit work in progress, most importantly, it is not
complete with regards to text rendering. More specifically, the server
applications and other parts of the appserver might set a font on the Painter
and this might mess up the synchronization. But this happens on the Desktop's
Painter instance (only?), and so it is not a problem. I did observe some
drawing bugs with this patch though, so bug reports are welcome, particularily
how to reproduce these bugs reliably.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21643 a95241bf-73f2-0310-859d-f6bbb57e9c96
client, when the connection is stopped. But cache the "reason" of the
notification, and join it with the next one, when B_DIRECT_START is
notified. Experimental, could be reverted.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21063 a95241bf-73f2-0310-859d-f6bbb57e9c96
of BMallocIO. Added an additional constructor to handle a file. This is
in preparation of implementing BView::SetDiskMode().
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20996 a95241bf-73f2-0310-859d-f6bbb57e9c96
app_server for this; added a new AS_IS_FRONT_WINDOW command for this.
For example, clicking on the menu bar to bring windows to front in FFM mode
does work now.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19725 a95241bf-73f2-0310-859d-f6bbb57e9c96
LockExclusiveAccess() (meaning more or less access to the
frame buffer)
* extracted the AGGTextRenderer to be a global instance used
by each Painter instance (currently, it is thread safe because
of the global font lock, so there is some work left in this
regard)
* gave every ServerWindow it's own DrawingEngine instance, this
is work in progress. So far, there doesn't seem to be a regression,
but less fighting over the exclusive access to the frame buffer, now
each ServerWindow thread can draw in parallel. There is room for
improvement, plus I think I'm leaking the DrawingEngine...
* changed the locking for the software cursor. ShowSoftwareCursor()
can only be called if HideSoftwareCursor(BRect) returned true, or
if you called the generic HideSoftwareCursor(), since it needs
to keep the cursor lock and unlocks in Show...!
* some clean up and renaming in Decorator and friends
* moved PatternHandler.h to live along with the .cpp
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19427 a95241bf-73f2-0310-859d-f6bbb57e9c96
various places. Implemented SetLineMode op for BPicture, fixed shape
drawing (I accidentally broke it in the previous commit).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19264 a95241bf-73f2-0310-859d-f6bbb57e9c96
Hopefully fixed all the problems. Reported by
Marc Flerackers.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19241 a95241bf-73f2-0310-859d-f6bbb57e9c96
the pen size). Added scale handling. Removed duplicated AS_SETPENSIZE
handler in ServerWindow
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19130 a95241bf-73f2-0310-859d-f6bbb57e9c96
* ServerApp was accessing ServerWindow::Window() (while having the app window
lock held), but in fact, there was no guarantee it already existed, or was
added to the Desktop.
* Therefore, the Window() semantics have changed to only return a window in
case the window exists *and* has been added to the desktop (the latter
constraint might be lifted again, though). Therefore, it doesn't work
for offscreen windows, and should not be used within ServerWindow code
anymore.
* This fixes bug #686 and maybe others as well.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17878 a95241bf-73f2-0310-859d-f6bbb57e9c96
when enabled, and B_NORMAL_WINDOW_FEEL when disabled. IOW when enabled, no
other windows can interfere.
* Therefore, it's no longer necessary to have the screen_blanker window
use kWindowScreenFeel - it will set its window to full screen as long
as the blanker runs.
* Added a AS_APP_CRASHED notification in the app_server that will remove
all kWindowScreenFeels from the windows of the crashed app.
* This is now used by the debugger to ensure that the debugger alert will
be visible.
* Factored out a DesktopLink class out of the BRoster::_ActivateApp()
method. This class is now also used in the new BRoster::_ApplicationCrashed()
method as used in the debug_server (via BRoster::Private).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17785 a95241bf-73f2-0310-859d-f6bbb57e9c96
* The overlay options as part of BView::SetViewOverlay() are now passed over
to the graphics driver - looks like the color key stuff cannot be turned
off (at least not via the Be API).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17323 a95241bf-73f2-0310-859d-f6bbb57e9c96
source file.
* An overlay is now also hidden in case its is removed from the window.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17209 a95241bf-73f2-0310-859d-f6bbb57e9c96
is currently broken, mode switches probably fail or result in sudden death
(didn't try) it's good enough for Radeon cards and VLC (might work with
others as well).
* Implemented follow modes for view bitmaps (wasn't taken into account at
all before).
* Switched to a darker overlay color for now (dunno what exactly makes a
good candidate there, but this one is good enough for now).
* Added TODO about a race condition in AS_LAYER_SET_VIEW_BITMAP.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17208 a95241bf-73f2-0310-859d-f6bbb57e9c96
Since ServerWindow removed itself from its ServerApp in _PrepareQuit(), it could
happen quite easily that the ServerApp was deleted before the ServerWindow - and
since deleting WindowLayer as part of that referenced the ServerApp, it crashed.
Now, adding/removing is both done by the ServerWindow in Init() respectively
the destructor.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17198 a95241bf-73f2-0310-859d-f6bbb57e9c96
to cut down on BRegion related allocations, cannot really tell
if it speeds things up
* used the new BRegion pool in WindowLayer and ViewLayer whereever
a BRegion was used on the stack
* fixed the debugging stuff in MultiLocker - it will get you into
the debugger if you
- try to nest read locks
- try to write lock when your are a reader already
- don't match up nested locks when your a writer
-> but only if you #define DEBUG 1 in the .cpp, is off by default now
* went over WindowLayer, ServerWindow, Desktop and a few other places
and fixed the locking for use with the MultiLocker, the "a reader can
not become a writer" is especially tricky, feel free to review the
changes
* activated the MultiLocker, I tested this quite a bit, if there are
problems simply turn on DEBUG and you should drop into the debugger
right where the problem is... hope all is good
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17046 a95241bf-73f2-0310-859d-f6bbb57e9c96
This lightens the problem in bug #98 a bit, but doesn't completely fix it; you
still don't see any items in that list on the switch, but they now appear again
when you scroll around there.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16997 a95241bf-73f2-0310-859d-f6bbb57e9c96
it and rebuilding it on the server side (that causes a huge speed
up for regions containing many rects)
* There is a method in ServerLink that could have been used, but I
actually needed to add the direct BRegion support to LinkReceiver
* added LinkReceiver as a friend to BRegion class
* ServerApp and ServerWindow keep the CursorManager locked after they
have retrieved a cursor until they have called Acquire() on the
cursor. (Axel: what good is using atomic* stuff in Acquire() and
Release() if we have to protect this by a lock anyways?)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16957 a95241bf-73f2-0310-859d-f6bbb57e9c96
even though we might need something similar, we can't use it (since it was
based on BGet++).
* Removed BGet++, it's not used anymore.
* Removed ServerMemIO class, was never used.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16830 a95241bf-73f2-0310-859d-f6bbb57e9c96
in HWInterface::_DrawCursor(). Axel, even though we
understood the problem, we didn't really fix it back
then: When the sync flag was set to true in
BView::SetViewCursor(), the link was only flushed,
which means that the function still returned before the
ServerWindow thread processed the message. This means
that the race condition (the cursor being immediately
deleted after SetViewCursor returns, which might be
processed in ServerApp thread before the SetViewCursor
request in ServerWindow thread) still existed. I changed
SetViewCursor now to do a real sync (wait for the
ServerWindow reply) before returning. The alternative
would be to set the fPendingViewCursor flag in either case.
Anyhow, I could reproduce the error quite reliably before
this change, and now it is gone... here is to hoping!
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16809 a95241bf-73f2-0310-859d-f6bbb57e9c96
likewise, while the user moves a window around, programmatical moves are ignored
as well.
This fixes bug #264.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16743 a95241bf-73f2-0310-859d-f6bbb57e9c96
this saves us some locking headaches and solves a possible deadlock in
ServerApp::Activate().
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16688 a95241bf-73f2-0310-859d-f6bbb57e9c96
of the view currently under the mouse, or the application cursor, if the view doesn't
have its own cursor (ie. it will no longer set the wrong cursor in certain situations).
* AS_DELETE_CURSOR has no longer an influence on the application cursor, as this grabs
a ref for its own use - this fixes bug #275.
* AS_SET_CURSOR no longer sets the cursor when the application is not active.
* Minor cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16678 a95241bf-73f2-0310-859d-f6bbb57e9c96
take an empty region as an indication to remove the clipping, but on R5,
this is actually valid... this patch fixes the problem
* the ViewState::clipping_region is now consistently used to memorize
the user defined clipping of the view state instead of being sometimes
used to cache the current view clipping
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16656 a95241bf-73f2-0310-859d-f6bbb57e9c96
free to continue (it would be nice to be notified before, though, in case
I get to it again in the next weeks).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16561 a95241bf-73f2-0310-859d-f6bbb57e9c96
windows to front (or minimize them).
* Desktop::ActivateWindow() no longer crashes in case the window to be activated
is not on the current workspace - instead, it doesn't do anything at this
point. IOW it doesn't handle workspace activation at all, yet.
* Renamed ServerWindow::GetWindowLayer() to ServerWindow::Window().
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16550 a95241bf-73f2-0310-859d-f6bbb57e9c96
holding the window lock.
* Run() is now called before creating the window in the app_server when
Show() is called for the first time (which is now checked with fRunCalled
instead of some thread arithmetics).
* Minimize() now sends the show level of a window to the app_server, so that
it can actually determine if minimizing or maximizing the window should
have any effect. This fixes bug #225.
* fShowLevel's meaning is now reversed; when it's above zero, it now means
the window is shown (before, a level less than 1 meant shown). This definitely
better fits its name :)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16536 a95241bf-73f2-0310-859d-f6bbb57e9c96
without a lock).
* Renamed private methods to start with the '_' symbol.
* Removed superfluous SetLayer[Font]State() and moved back those one-liners into their
AS_* handlers.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16535 a95241bf-73f2-0310-859d-f6bbb57e9c96
* all cursors owned by a team are visually different,
or (iaw) an already existing cursor is reused when
it is set by the client again
* changed various occurances of cursor data from "int8*"
to "uint8*"
* ServerCursors also remember the R5 data from which
they were created
* the reference counting and destruction of
ServerCursors changed: The cursor knows it is attached
to a CursorManager and one can simply use
ServerCursor::Acquire() and Release() and the reference
counting and everything is being taken care of
* destroying a ViewLayer will now correctly release a set
ServerCursor
* fixed a race condition when setting a cursor through
BView::SetViewCursor(): If the client code looks like this:
BCursor cursor(cursorData);
someView->SetViewCursor(&cursor, false);
there is a relatively high chance the BCursor destructor
told the ServerApp thread to destroy the cursor before
the ServerWindow thread got to "acquire" the cursor for
use by the view layer. The very same problem is likely the
reason that SetViewCursor works to unreliably on R5, even
when the "sync" flag is set to "true" (although it should
theoretically work in that case).
all these fixes make WonderBrush work fine again with the
new support of custom cursors.... coded by axeld and myself
(the joys of pair programming :-)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16521 a95241bf-73f2-0310-859d-f6bbb57e9c96
all those error output from the app_server.
* AS_LAYER_DELETE now gets a token, no longer frightening choice of parent.
* Removed locking in RemoveChild(); it has to be called locked now.
* Removed AS_LAYER_DELETE_ROOT as it's no longer needed.
* Removed support from BView for being PR3 compatible.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16424 a95241bf-73f2-0310-859d-f6bbb57e9c96
