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
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
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
dir_remove() did not normalize the path, and thus, could forward a "." as
name for the removed directory - which BFS didn't catch because it assumed
our VFS would work correctly...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17165 a95241bf-73f2-0310-859d-f6bbb57e9c96
handled correctly.
* The path of moved styles is now updated (also when their parent directories
are moved).
* FontManager::_AddPath() can no longer crash when you leave the _newDirectory
parameter set to NULL.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17163 a95241bf-73f2-0310-859d-f6bbb57e9c96
vnode is not becoming unbusy (right now it even panics, but that can be removed
later on).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17161 a95241bf-73f2-0310-859d-f6bbb57e9c96
* The private general_info structure is now setup - that fixes a part of bug #502;
NetPositive's bar remains black, though.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17160 a95241bf-73f2-0310-859d-f6bbb57e9c96
* pressing the escape key now exits the window as it should be (SetEventMask()
was called in the constructor, but has no effect as long as the view isn't
attached to a window).
* The window is now font sensitive (fixing bug #450).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17159 a95241bf-73f2-0310-859d-f6bbb57e9c96
sure all messages that could trigger an update have
actually arrived at the server
* small clean ups here and there, some clarifications in
comments
* check for the return value of Lock() in DisableUpdates()
and EnableUpdates()
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17158 a95241bf-73f2-0310-859d-f6bbb57e9c96
case the window receives the keyboard message).
This fixes bug #411.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17156 a95241bf-73f2-0310-859d-f6bbb57e9c96
