which triggers waiting on the retrace semaphore in app_server
just before drawing the bitmap. This potentially removes any
additional delay when doing this client side. Completely untested.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@39097 a95241bf-73f2-0310-859d-f6bbb57e9c96
recognizes a double click as double click if the action didn't change.
* This fixes bug #6699.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@39064 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Use layout API in preview printer add-on.
* Use layout API in some dialogs in PDF Writer.
* Removed unused class PrinterSetupWindow from PDF Writer.
* Improved layout in print_server configuration dialog.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38986 a95241bf-73f2-0310-859d-f6bbb57e9c96
passed to the pixel format methods. Don't use a dummy color
for drawing dots. (Untested, but should fix Clockwerk time
line objects drawing)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38955 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Make sure that turning off anti-aliased font rendering
also works when subpixel-anti-aliasing is used.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38831 a95241bf-73f2-0310-859d-f6bbb57e9c96
the ServerPicture calls those itself from SetOwner().
Since there are asserts in ServerPicture about fOwner,
it was easiest to fix the code by using *only* SetOwner()
from within ServerApp to add or remove pictures.
* SetOwner() was broken, since it called a method which
potentially removed the last reference and then still
accessed memory of the now free'd ServerPicture instance.
The easiest fix is to just increase the reference count
temporarily.
* SetOwner() wrongly returned false when the new owner was NULL.
* NestPicture() should simply add it's own reference. There
are two places where it is called, and only one of them
added the extra reference. The other one only acquired the
implicit reference that the ServerApp owns, but pictures
that remove nested children remove a reference from them.
This could leave stale pointers around of course.
* Added more asserts about fOwner.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38484 a95241bf-73f2-0310-859d-f6bbb57e9c96
to avoid someone drawing into it at the same time. In a debug
build, this avoids hitting an ASSERT.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38478 a95241bf-73f2-0310-859d-f6bbb57e9c96
message loop more clear, both in the code and also via
comments. I get the occasional drop into the debugger
because MultiLocker says the Readlock has been acquired
twice. I don't see how it is possible from the code and
it could be another bug in the MultiLocker debugging
facilities, but the code should be clearer now anyway.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38477 a95241bf-73f2-0310-859d-f6bbb57e9c96
the same mechanism needs to be applied as for Decoders,
so that user add-ons are always found before system
add-ons.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38360 a95241bf-73f2-0310-859d-f6bbb57e9c96
to return false. This happened when searching decoders in
/boot/common/add-ons/media/plugins, which does not exist on a default image
and thus broke finding *any* decoder, it only worked when you had some in
/boot/home/config/add-ons/media/plugins... sorry and thanks Alex Wilson
for the heads up!
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38347 a95241bf-73f2-0310-859d-f6bbb57e9c96
we need to remove its globally registered formats
from the FormatManager.
* When searching decoders for a given format, we need
to search by add-on directory, since the decoder
list will not stay sorted once some have been removed
or added after the initial add-on scan.
These fixes make it finally possible to rebuild media
plugins and have the media_server pick up the changes
without needing a restart.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38338 a95241bf-73f2-0310-859d-f6bbb57e9c96
missing any way to remove previously registered formats.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38337 a95241bf-73f2-0310-859d-f6bbb57e9c96
The fWriterThread and fWriterStackBase were reset in WriteUnlock()
without holding any lock. While running a DEBUG compile of app_server,
I ran repeatedly into an assertion in the mouse event thread, that
it was not the write lock holder anymore when calling WriteUnlock().
My theory (also discussed with Axel, thanks!) is as this: Some random
thread holds the write-lock. The mouse event thread is allowed to run
when that thread releases the write-lock, but the thread is rescheduled
before it resets the write-lock-holder values (B_DO_NOT_RESCHEDULE only
means rescheduling is not forced, but it may happen anyway). Then the
mouse thread runs, acquires the write-lock, sometime later the original
thread continues to run, and completes WriteUnlock() with resetting the
holder values. When the mouse thread continues to run and eventually
calls WriteUnlock(), the holder values do not match anymore. The theory
is further confirmed by the fact, that fWriterThread was always -1 in the
assert and not some random other thread.
As mentioned, only affected DEBUG builds of app_server, in release builds,
another lock protects the holder values.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38331 a95241bf-73f2-0310-859d-f6bbb57e9c96
to BEntry and back to entry_ref. This ommits a check to
BEntry::InitCheck(), but AddOnMonitor should pass us only valid
entry_refs.
* Removed no longer valid TODO.
TODO: There is still some problem with reloading add-ons, once they have
been reloaded, they fail to instantiate properly, as if the entry_ref
is pointing to the wrong node.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38328 a95241bf-73f2-0310-859d-f6bbb57e9c96
It unloads any media_format mappings when an add-on
becomes unavailable, and consequently reloads the
supported formats and similar when the same add-on
becomes available again. Previously it would only
load previously unkown add-ons by node-monitor
events (unkown name). What also works is that user
add-ons shadow/hide system add-ons when installed,
and the system add-on will become effective immediately
when removing the user add-on again. One thing to
note is that certain IDs will not stay consistent.
I am not aware of an application for which it could
be a problem, most should rememeber codecs by name.
In any case, I only tested add-on events a lot, and
not so much the effects of unstable media_file_format
IDs, so it's possible there are regressions, though
only when installing new versions of add-ons, which
previously mostly required a media_server restart
anyway.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38282 a95241bf-73f2-0310-859d-f6bbb57e9c96
* make BDADDR_* macros refer to value types instead of addresses
* adjust all interfaces using bdaddr_t* to use (mostly const) refs instead,
which IMHO makes the interface & code clearer
* that got rid of a couple of const incorrectness casts
* some cleanup along the way
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38265 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Don't acquire the read-lock in WindowForClientLooperPort,
since MultiLocker does not support nested read-locks.
Use an assert instead, however the method does not appear
to be used anywhere at the moment.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38224 a95241bf-73f2-0310-859d-f6bbb57e9c96
had several problems: First of all it duplicated the FontCacheEntry
retrieval and locking code. Second it was really slow to do the whole
lookup for every single glyph. Third is used the FontManager without
locking, which could result to app_server crashes, mostly at startup,
while the FontManager thread was scanning the fonts and the glyph
layout was already using it. Forth it dereferenced a FontStyle
pointer without checking it against NULL. And lastly it didn't use
the font size of the original font for the fallback font.
The new algorithm addresses not only these, but also puts the glyphs
which are unsupported by a font and retrieved from the alternative
font, into the FontCacheEntry of the original font, so that the
HasGlyphs() check succeeds the next time around and does not need to
use the fallback algorithm anymore. There is also less manual management
of locking and FontCacheEntry recycling, this is now taking care of by
FontCacheReference objects on the stack.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38154 a95241bf-73f2-0310-859d-f6bbb57e9c96
which can do an alternative lookup of the glyphCode to glyphIndex
and who's FontEngine is used to retrieve the GlyphCache object.
The glyph however is inserted into the Cache of the original entry.
* GlyphCache objects are no longer looked up by index, but by charCode,
which should not be a functional change, but allows to lookup glyphs
from the cache for which the underlying FontEngine does not have
a code to index mapping.
* Fixed an operator precedence bug in the signature generation.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38153 a95241bf-73f2-0310-859d-f6bbb57e9c96
- First unregister listener reload decorators and then register new listener.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38070 a95241bf-73f2-0310-859d-f6bbb57e9c96
the window. This closes ticket #6429.
* Got rid of useless _Extract*() methods. Also removed the _ActionFor() variant
that only took a message.
* Removed unused "invalidate" variable in MouseUp().
* Coding style cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37998 a95241bf-73f2-0310-859d-f6bbb57e9c96
