of locking before processing the message (single/all window lock)
-> in most message cases, I could comment out the unlocking/locking which
switched to the different lock, because the required lock is now already held,
this removes some race conditions which were commented in the code already
* EventDispatcher::SetDragMessage() didn't lock the object, this would have
been bad if multiple windows tried to set a drag bitmap at once
* the Desktop object keeps track of mouse position and pressed buttons, so
that it doesn't need to lock the EventDispatcher for sending fake mouse
moves to windows on show/hide of windows (solves some cases of possible
dead locks with the new locking strategy)
* the keyboard EventFilter switches the current workspace asynchrnously from
the Desktop thread (another source of possible deadlocks)
* the "reader is trying to become writer" check in MultiLocker is only used
in DEBUG mode now
As a summary: It would be nice if ServerWindow used a readlock for all messages
it processes itself, and forwards all messages for which it needs a write lock
to the Desktop thread. All cases where either the Desktop or the ServerWindow
mess with the EventDispatcher are possible sources of deadlocks. This is solved
right now by making sure that the lock is released before using the
EventDispatcher.
I have not observed any deadlocks while switching workspaces and launching
many apps anymore, neither crashes. But I have not tested extensively except
for in the test environment. That being said, I could reproduce the problems
on first try before in Haiku.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22410 a95241bf-73f2-0310-859d-f6bbb57e9c96
client and the server. This should fix bug #1490, but I haven't tested it yet.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22388 a95241bf-73f2-0310-859d-f6bbb57e9c96
by now, I feel there is too much code involved in this... I guess I should
really move this to stuff to ViewLayer::ConvertToScreenForDrawing()...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22223 a95241bf-73f2-0310-859d-f6bbb57e9c96
* put message codes for Begin/EndRectTracking() into giant switch... not
actually implemented though
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22220 a95241bf-73f2-0310-859d-f6bbb57e9c96
needs to be recalculated when the scale changes.
Also call ResyncDrawingState() in exit_state_change(). This fixes the
pen size test in FlattenTestPicture.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22215 a95241bf-73f2-0310-859d-f6bbb57e9c96
always put between window screens and modal all windows (before floating
all ones), so a BWindowScreen couldn't have menus at all.
Now, they behave more like floating app windows, just that they float above
all other application windows, such that all window feels (also BWindowScreen)
can now have menus.
* Reenabled keyboard redirection to the top most window in case it's a menu;
bug #1152 no longer applies due to the above change.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22149 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Since the app_server launched the input_server, it would also get notified
when the latter died via a signal - but LinkReceiver could return B_INTERRUPTED
in that case (it didn't check the return value of port_buffer_size()) which
the app_server misinterpreted and quit itself... this fixes the hanging part
of bug #1298.
* But the input_server still wasn't restarted, because the Registrar had it
still listed as being running. Now, the Registrar checks not just periodically
for died teams, it will also check for it when a new application registers
itself. This fixes the rest of bug #1298.
* Removed the old (disabled) R5 style input_server launch mechanism from the
app_server.
* MessageLooper now prints a bit more information when a port is supposed to
have been deleted.
* The default implementation of MessageLooper::_GetLooperName() is now
returning the name of the semaphore of its BLocker instead of "unnamed
looper".
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22115 a95241bf-73f2-0310-859d-f6bbb57e9c96
have become more expensive, so maybe it is better to do what I proposed
in the ticket comments, and move the rounding of drawing command coordinates
into ViewLayer::ConvertToTopForDrawing() instead of handling it in
DrawingEngine and Painter
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22060 a95241bf-73f2-0310-859d-f6bbb57e9c96
possibly making them a little faster too
* mess with decorator button size calculation to make the whole layout scale
more agreeable with the font size (no more fixed offsets/insets), but it
is work in progress
* DefaultDecorator no longer allocated the border color array, it is part of
the object now
* small memory footprint optimizations in ViewLayer, Decorator and WindowLayer
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22003 a95241bf-73f2-0310-859d-f6bbb57e9c96
* origin is given in "outer" coordinate system therefore if there is a
previous state it has to be transformed. Please review if this is
required in OffsetOrigin() too.
* in Transform() we have to scale relative to the view origin not (0 /
0).
- optimized SetScale: saved one division
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21993 a95241bf-73f2-0310-859d-f6bbb57e9c96
as Marcus pointed out, having it outside wasn't thread safe. Moved
PicturePlayer into the BPrivate namespace.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21982 a95241bf-73f2-0310-859d-f6bbb57e9c96
* after this change, I have not spotted "left behind" cursors again, but it
might just be bad luck...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21966 a95241bf-73f2-0310-859d-f6bbb57e9c96
PicturePlayer to explain what we need to do. Don't write the
B_PIC_ENTER_STATE_CHANGE and B_PIC_ENTER_FONT_STATE ops until we fix the
problem (we don't care about them in our server side
implementation anyway). Font changes and state syncing work again.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21940 a95241bf-73f2-0310-859d-f6bbb57e9c96
of the function table, so if someone passes a smaller table, we avoid
calling invalid pointers.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21939 a95241bf-73f2-0310-859d-f6bbb57e9c96
maybe this is too resource hungry, feel free to critisize... :-)
* the speedup is there, but not overwhelming
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21929 a95241bf-73f2-0310-859d-f6bbb57e9c96
AppendToPicture() (but still doesn't work :( ). Moved some functions
around in PictureDataWriter.h.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21925 a95241bf-73f2-0310-859d-f6bbb57e9c96
kept in a list by ServerApp, and deleted by its destructor.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21924 a95241bf-73f2-0310-859d-f6bbb57e9c96
stroke/fill polygon, stroke/fill bezier. some work towards drawing of
nested pictures.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21918 a95241bf-73f2-0310-859d-f6bbb57e9c96
* revised use of check_lock() versus do_owner_check() (do_owner_check()
is supposed to drop you into the debugger if there is no owner, otherwise
it behaves like check_lock())
* ConstrainClippingRegion() no longer transmits empty regions to the
app_server. I would have thought that my fix to ServerLink would have
solved the issue I was investigating, but only this commit fixes it.
Maybe the last commit would have fixed it if I did a "jam clean"...
* WonderBrush draws the icons again on mouse over...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21910 a95241bf-73f2-0310-859d-f6bbb57e9c96
BView implementation (client side)
* introduced some private methods for _Convert*(BPoint*) methods which avoid
doing the check_lock() thing in the recursion, also Origin() would likely
have communicated with the app_server all the time, since the origin bit
was needlessly invalidated, so some speedup should be achieved
* this should fix ticket #98
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21900 a95241bf-73f2-0310-859d-f6bbb57e9c96
implementation takes the byte count, even though it looks like this is
less efficient when the glyph count is already known (I tested to
optimize it away but it was not faster)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21891 a95241bf-73f2-0310-859d-f6bbb57e9c96
Painter, that is needed to be able to tell if anti-aliasing is to be used,
since the flags in the font can be overruled by the flags in the view...
* fixes aliased fonts reliably, tested with FontDemo
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21869 a95241bf-73f2-0310-859d-f6bbb57e9c96
this for a long time... what happens when the app_server has requested a
redraw, but the client sends some drawing commands before starting the
redraw session? This would be the case, for example, when TextViews got
notified of their parent window becomming active (they would invert the
selection outside of any update session). When there was an additional
expose event, the app_server would already have the background cleared, so
the lonely "invert" command would invert the freshly painted background. Then
the normal Draw() of the TextView would be called because of the expose event.
By the time the text was rendered, it was rendered on the inverted background,
then the normal Draw() contained another "invert" command to invert the
region of the selection. Thus inverting just the text, and the background
twice. Solution:
* introduced a special handling for drawing commands arriving between
requested update session and beginning of that session: the pending
update region is clipped from the region the client is allowed to draw in.
* fixes funny text rendering in the selected part of text views. For example
ticket #908.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21867 a95241bf-73f2-0310-859d-f6bbb57e9c96
* fixed a bug in the font cache, the signature was generated in one way
(rendering type) while the initialization of the font engine could
use another way
* should fix non-antialiased straight text
* weird non-transformed text in FontDemo
* generally not using vector glyphs when it was supposed to use them (rotated
or sheared text, or non-antialiased text)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21866 a95241bf-73f2-0310-859d-f6bbb57e9c96
(fixes ticket #1367, stefano I thought you knew that I meant this in an
earlier mail)
* move_pen_by() looked wrong in ServerPicture, have not tested though
* make sure the pen location is adjusted after stroke_line() and draw_string()
in ServerPicture
* set_pen_location() does not need to update the Painter drawing state
* ServerWindow AS_LAYER_SET_PEN_SIZE needs to set the resulting pen size of
the drawing state stack, not the one set on the current state
* ServerWindow AS_LAYER_GET_PEN_SIZE needs to return the current state's
size, not the result of the stack
* small cleanups
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21855 a95241bf-73f2-0310-859d-f6bbb57e9c96
and that the previous pattern is restored after execution
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21853 a95241bf-73f2-0310-859d-f6bbb57e9c96
ServerFont::GetBoundingBoxesForStrings() (ScreenSaver no longer crashes as reported by Brian
Verre on the mailing list).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21846 a95241bf-73f2-0310-859d-f6bbb57e9c96
and then use hardware acceleration... found out this is what our
BTextView is actually using, that's why it never used hardware
acceleration for invert rect/region before. Have not tested this on
real hardware yet.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21843 a95241bf-73f2-0310-859d-f6bbb57e9c96
a BPicture, though I'm not yet sure if I should do it there on when
playing the picture...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21836 a95241bf-73f2-0310-859d-f6bbb57e9c96
offset works correctly. Drawing a BShape using a BPicture is currently
broken. Stephan, any insight on what it's changed about shape drawing ?
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21835 a95241bf-73f2-0310-859d-f6bbb57e9c96
drawing a string inside a picture and then playing that picture
triggered a debugger call. Fixed.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21823 a95241bf-73f2-0310-859d-f6bbb57e9c96
before (although there should be much less lock contention)
* with this change, there is quite a bit of cleanup, text drawing is now
about 20% faster than before the original changes to font caching,
mostly due to turning off the kerning feature, which at the moment
gives absolutely no benefit. The correct way of doing it might be to
use kerning depending on the provided glyph spacing mode
* removed fPenLocation from Painter, the usage should be more correct now,
since it is now consistently applied before the coordinate transformation
from view to screen (also for DrawShape() now, before any view scaling
and origin offset)
* Painter no longer has it's own instance of a ServerFont, instead it uses
its AGGTextRenderer instance, which was per Painter again after the
last change, and not global anymore, made _UpdateFont() useless
* When using GlyphLayoutEngine, it supports a second pass with the same
FontCacheEntry through the introduction of a FontCacheReference. This
speeds up DrawString a little, since it needs to calculate the bounding
box for the string, and then draw the string in a second pass. This is
now done with only one FontCacheEntry lookup
* I also tried to optimize the on-the-fly conversion of UTF8->CharCode away,
since it was done four times per DrawString, but surprisingly, it proofed
to be a slight slowdown.
* introduced a shortcut in DrawingEngine::DrawString() which avoids
calculating the bounding box, we are now a tiny bit faster to figure
out that we don't need to draw any string than Dano
In the test environment (drawing to offscreen bitmap and blitting to
screen eventually), text rendering is now about 3.7 times _faster_ than Dano
text rendering (directly to screen), for untransformed text. Unfortunately
I cannot test on the same machine in accelerant using version of the test
environment.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21822 a95241bf-73f2-0310-859d-f6bbb57e9c96
and DrawString() without
* this change also includes adding the penlocation to the shape to-screem
coordinate conversion (temporarily breaks shape rendering, will be fixed
in next commit)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21821 a95241bf-73f2-0310-859d-f6bbb57e9c96
removed font_support folder
* ServerApp can use ServerFont::StringWidth() directly again
* more ServerFont functions implemented via GlyphLayoutEngine and
custom consumer
* extended GlyphCache data structure to hole the left/right insets
of the glyph shape between its advance width, took it from the earlier
ServerFont implementation, have not tested if that gives same result
as R5
* TODO: implement GetGylphShapes via GlyphCache, although it might not
look as clean as it does now
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21805 a95241bf-73f2-0310-859d-f6bbb57e9c96
* the previous AGG implementation is superfluous
* the new implementation is based on that one, but in a way that allows
read/write locking to the list of cache entries (fonts) as well as
read/write locking to the cached glyphs per individual font cache entry
* new GlyphLayoutEngine.h, which is to be the central place for layouting
glyphs along the baseline.
It handles the locking for getting the font cache entries.
It works by giving it a template class GlyphConsumer which does the
actual work.
* changed AGGTextRenderer to use the new font cache
* changed ServerFont::StringWidth(), and the bounding box stuff to use it
* changed DrawingEngine, it doesn't need the global font lock anymore
* our BFont thought that GetBoundingBoxesAsGlyphs and GetBoundingBoxesAsString
is the same, which of course it isn't, hence the two separate functions...
AsGlyphs just gets the bounding box of each glyph in a string, not treating
the string as an actual word
AsString adds the offset of the glyph in the word to the bounding box
* changed ServerProtocol.h accordingly for the different bounding box meaning
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21797 a95241bf-73f2-0310-859d-f6bbb57e9c96
It now at least frees all memory when the object is deleted. Reported by Jonas - thanks!
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21687 a95241bf-73f2-0310-859d-f6bbb57e9c96
of the active ViewLayer is now always mirrored in the Painter instance
of a ServerWindow, so that it doesn't need to be synced on every drawing
command, this was previously incomplete for font handling
* removed the DrawState parameter from all the DrawingEngine functions
* adjusted ServerWindow and ServerPicture accordingly
* made sure that string related functions used by non-drawing related
parts (ServerApp, Decorator) don't interfere with the current drawing
state
* moved AS_SYNC handling from _DispatchViewMessage to _DispatchMessage,
it is actually a window message and doesn't require fCurrentLayer to
be valid
* fixed bug #1300, fCurrentLayer was not updated when a ViewLayer was
deleted by client request which happened to be fCurrentLayer (I am now
handling it so that the parent becomes the current layer, could be
wrong)
* AGGTextRenderer is no longer using it's own scanline, which should save
a few bytes RAM, the Painter already had such an object
* StringWidth() in AGGTextRenderer is now taking the escapement_delta into
account
* Painter::StrokeLine() doesn't need to check the clipping as much, since
that is already done in DrawingEngine
* if a ServerWindow message is not handled because fCurrentLayer is NULL,
a reply is sent in case the messages needs it (client window could
freeze otherwise, waiting for the reply for ever)
* removed unused AS_SET_FONT and AS_SET_FONT_SIZE
* added automatic RGBColor -> rgb_color conversion to RGBColor.h
* minor cleanup for 80 char/line limit
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21685 a95241bf-73f2-0310-859d-f6bbb57e9c96
I "ported" the region implementation from XOrg to work on BRegion data.
This resulted in pretty much the same code structure as before, with
RegionSupport.cpp containing the messy details. Only now it _is_ really messy
from a code beauty point of view. I didn't exactly feel like cleaning it
up right now... but I guess I will have to.
So what does this mean - our BRegion implementation was very slow (no offense!),
and on top of that it scaled very badly with more and more rects. The new
implementation seems to be on par with the very fast R5 implementation and
the data looks exactly the same too. BRegion is very performance critical
for the app_server, and I cannot wait to try this on my slow computer...
Some changes are noteworthy: The right and bottom coordinates of
BRegion internal data are now exclusive! I inherited that from the
XOrg implementation and didn't feel like changing the code, seeing it
is probably tested quite well. The conversion is handled transparently.
Secondly, constructing a BRegion with just one rect is not invoking
malloc anymore for the member data, this makes it much more efficient
to use temporary BRegions with just one rect, both externally and internally
in the BRegion implementation.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21665 a95241bf-73f2-0310-859d-f6bbb57e9c96
crashed. Turns out a call I use, BFont.GetBoundingBoxesForStrings was not
implemented, and worse, there was bug in how the ServerApp read the parameters
from the link. This was easy to fix to stop app_server from crashing, but it
took me a while to figure out how to implement GetBoundingBoxesForStrings.
Anyhow I implemented an initial version which works fairly well for now. I
don't think the width is quite right, but it seems to match StringWidth(), so
I guess it is good enough for now.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21652 a95241bf-73f2-0310-859d-f6bbb57e9c96
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
looking up the color in the pattern, this is needed because before,
patterns were always drawn with the virtual origin in screen coordinate
space, but they need to be drawn with view coordinate origin taken into
account (will be implemented in a forthcomming commit)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21639 a95241bf-73f2-0310-859d-f6bbb57e9c96
FontFamily.h/cpp (just for the reason that this is how we do it mostly
everywhere)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21637 a95241bf-73f2-0310-859d-f6bbb57e9c96
yet. Also, BBitmap::LockBits() should probably fail when the Bits() are NULL.
* The downside is that many more classes now know of each other.
* Cleaned up the work divided between the BitmapManager and the Overlay class.
* Fixed a memory leak in AS_CREATE_BITMAP in case the bitmap could not be added to
the ServerApp's bitmap list.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21512 a95241bf-73f2-0310-859d-f6bbb57e9c96
it's own (static) method. In case setting the display mode fails, the returned mode
is now checked for validity as well.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21282 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
* test the actually visible view area against dirty region,
(this avoids making the client window call the Draw() function of views,
even though all the drawing would get clipped on the server side)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20756 a95241bf-73f2-0310-859d-f6bbb57e9c96
now, at least). This feature wasn't used yet anyway, and turning it
off cures bug #1152.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20662 a95241bf-73f2-0310-859d-f6bbb57e9c96
sheared or put to "false bold"), the actual problem was resolved
with the last revision
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20480 a95241bf-73f2-0310-859d-f6bbb57e9c96
