that application quits; this just prevented us to see who the culprit is.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17213 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
* some fixes to make screen_blanker wait_for_thread() instead of
killing the screen saver thread, BScreenSaver::Stop() is now called
as well as its destructor
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17206 a95241bf-73f2-0310-859d-f6bbb57e9c96
this avoids linking against libroot.so's glob symbol when user lib provides it
fixes bug #535. this implies libroot.so's glob implementation could need a review.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17202 a95241bf-73f2-0310-859d-f6bbb57e9c96
is managed for those bitmaps:
- the shared client memory mechanism is used to allocate a small overlay_client_data
structure that contains the actual buffer and a semaphore that you have acquire in
order to access it.
- LockBits()/UnlockBits() now have a function: you need to call them before accessing
the overlay buffer, and you need to keep that lock until you're done with it.
* The overlay cookie is now an extra member of the ServerBitmap class.
* Removed fInitialized from ServerBitmap - IsValid() now just checks the buffer associated
with the bitmap.
* ViewLayer::Draw() will now handle overlay bitmaps specially and will draw the overlay
color instead of any contents (this is currently in ugly pink, but will become some
dark color later on).
* All what's missing from actually being able to use overlays now is to configure
them so that they are shown on screen. VLC will now show an empty pink window when
overlay video is enabled.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17201 a95241bf-73f2-0310-859d-f6bbb57e9c96
to live with the default settings (which hopefully have *two* arrows per side, though,
won't they, Stephan? :-))
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17199 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
current display_mode doesn't matter, only the one where the overlay is shown later
does.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17197 a95241bf-73f2-0310-859d-f6bbb57e9c96
created as the graphics driver does.
* Also, B_BITMAP_RESERVE_OVERLAY_CHANNEL should now work as expected.
* We're no longer using the B_OVERLAY_COUNT hook anymore - that one really
looks like a misconception to me; I don't see how it can be useful.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17196 a95241bf-73f2-0310-859d-f6bbb57e9c96
via the graphics driver (but not yet shown on screen).
I probably got the meaning of the "overlay count" wrong - I guess that you
can allocate any number of overlay bitmaps, but can only see "overlay count"
on screen at a time (right now, I only allow to create "overlay count" bitmaps).
Stephan?
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17193 a95241bf-73f2-0310-859d-f6bbb57e9c96
class name. Also returns the actual error from the
BMessage::AddData() if there was any. Please people, correct
code like that if you spot this elsewhere and don't write
such code anymore.
* the BMessage constructor should be more robust.
* the copy constructor takes the possibility into account
that BitsLength() does not match.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17187 a95241bf-73f2-0310-859d-f6bbb57e9c96
* removed TODO in DragMessage about reference counting, since
it already happens
* use _FlushIfNotInTransaction when moving/resizing a view
programmatically, so that it usually happens instantly.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17186 a95241bf-73f2-0310-859d-f6bbb57e9c96
a (hopefully) cute rocket. It's not quite as readible as
the other overlays, so I might work on it some more. Also
note that it is a manned rocket, as per the window, so I
hope it cannot be mistaken for a missile. :-)
BTW - talk about self contained development, the icon was
done on Haiku!
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17185 a95241bf-73f2-0310-859d-f6bbb57e9c96
added some more posix definitions, though they might be never used in Haiku
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17184 a95241bf-73f2-0310-859d-f6bbb57e9c96
1. Renamed the Image menu items "Mirror Vertical" and "Mirror Horizontal" to "Flip Sideways" and "Flip Upside Down", respectively. This also involved changing the code to match the new names, for consistency.
2. Fixed a bug where zooming in and out would result in the image moving off center. This was due to the bitmap width and height not being recalculated after applying the zoom factor and therefore throwing off the calculations to find the rect for the center.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17182 a95241bf-73f2-0310-859d-f6bbb57e9c96
when selected, we only use GuessMimeType() when the type isn't found
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17173 a95241bf-73f2-0310-859d-f6bbb57e9c96
ViewLayer (for example, fixes NetPositive rendering
HTML with a background image)
* use BRegion pool everywhere in ViewLayer
* WindowLayer update sessions distinguish between
different reasons for the update: exposed and requested -
on expose updates, the view backgrounds are cleared
immidiately (as on R5), to keep the time previous stuff
keeps showing as short as possible, while on requested
updates, the background clearing is delayed until the
client draws something, to keep the time until the client
fills a view with content as small as possible to reduce
flickering (might need more work, could be buggy yet)
* HWInterface and DrawingEngine support delayed syncing to
the graphics hardware at least for FillRect/Region. The
speed up gained by this is minor though.
* HWInterface cursor rendering uses a bit of rounding to
avoid the slight transparent shadow around the cursor
(I don't know if it is fully correct though, at least the
shasow disappeared)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17172 a95241bf-73f2-0310-859d-f6bbb57e9c96
