* Mesa doesn't compile yet, as some PPC specific stuff seems to be
missing, Philippe?
* Cortex and some other stuff has been marked x86-only, although
it's more of a "GCC 2.95.3"-only.
* I'm not sure if it's a bug in GCC 4, or if that's what the C
standard demands, but sizeof(some_type::some_field) is not
valid anymore :-/
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17515 a95241bf-73f2-0310-859d-f6bbb57e9c96
it is added our removed to another view, this is
taken care of in View.cpp until we find something
better
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17511 a95241bf-73f2-0310-859d-f6bbb57e9c96
ViewLayer::SetViewBitmap() did not show the overlay, only updated it.
* Simplified overlay handling a bit, removed Overlay::Show(), and IsVisible(),
replaced Update() by Configure().
* Made similar changes in the HWInterface as well.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17504 a95241bf-73f2-0310-859d-f6bbb57e9c96
to bordered window (ie. VLC when switching back from full screen mode).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17503 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Overlay::SetView() no longer calls HWInterace::UpdateOverlay() if it's currently
hidden.
* ViewLayer::UpdateVisibleDeep() now calls _UpdateOverlayView() before showing
the overlay.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17489 a95241bf-73f2-0310-859d-f6bbb57e9c96
the overlay buffer changed. Found by Marcus.
As a result, the overlay window looks much smoother when moving it around (and it
even starts to move when you don't change the overlay bitmap at all...).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17484 a95241bf-73f2-0310-859d-f6bbb57e9c96
turned off - note also, that only the 32 bit mode is currently hardware accelerated!
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17421 a95241bf-73f2-0310-859d-f6bbb57e9c96
in that we try really hard to let it succeed. If setting the desired mode failed,
we now try almost anything to get a working mode.
Since the kernel also knows the VESA mode, maybe we should better ask that one for
the current mode, as most drivers probably haven't got B_GET_DISPLAY_MODE implemented
in the we're using it.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17355 a95241bf-73f2-0310-859d-f6bbb57e9c96
safe in the sense that it no longer clobbers fDisplayMode in case B_GET_DISPLAY_MODE
fails. This fixes bug #564 resp. #566.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17353 a95241bf-73f2-0310-859d-f6bbb57e9c96
Made sure that fDisplayMode is not modified if fAccSetDisplayMode failes,
as on my system fAccGetDisplayMode did return values that would crash
because of a virtual_width beeing 0.
Generally, this whole class is pretty broken, as the functions modify *some*
class member variables before eventually failing.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17352 a95241bf-73f2-0310-859d-f6bbb57e9c96
This fixes bug #558; Cortex floating windows have the B_AVOID_FOCUS flag set.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17341 a95241bf-73f2-0310-859d-f6bbb57e9c96
using the "normal" B_OP_COPY for lines and such that works more
like B_OP_OVER actually (for example, the slider in VLC will look
much better, but also other stuff)
* combined Stroke and FillEllipse() into DrawEllipse() and fixed
some longstanding issues, ellipses are now correctly placed
(aligned) and of the correct size
* removed locking in the DrawingEngine drawing functions, since
you need to have the DrawingEngine locked anyways for the
clipping to stay what it is (and that's already the case elsewhere
in the code)
* simplified ConstrainClippingRegion, the NULL version was never
useful and also locking is removed, see above
summary: slight speed improvements, cleanup and bugfixes...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17329 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
B_GET_ACCELERANT_CLONE_INFO (as that's what the caller actually wants).
Unfortunately, it's currently hard-coded to path names, that is, if there
is a driver out there that doesn't follow this quasi standard, it will
break this mechanism.
We should either change the driver interface to explicetly use path
names, or change the mechanism we're using (in BWindowScreen upwards to
the app_server) to the one as thought by Be.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17299 a95241bf-73f2-0310-859d-f6bbb57e9c96
immediately. Only if the mouse is released within a certain
time window (half a sec) and if it was not dragged (as on R5).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17285 a95241bf-73f2-0310-859d-f6bbb57e9c96
* If the window is on another workspace, the workspace will be
activated or the window will come to the current workspace
or nothing will happen depending on the windows flags. Tested
with WonderBrush, but I just now realise that it will also
fix activating a window in the Deskbar, which is on a different
workspace.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17284 a95241bf-73f2-0310-859d-f6bbb57e9c96
children of the view in question into account. Neither
are they included in the region being copied, nor are
views overdrawn by the copied contents. Also, the update
region is calculated from the region having been copied,
so that holes from children views are invalidated
correctly.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17268 a95241bf-73f2-0310-859d-f6bbb57e9c96
will not try to retrieve the retrace semaphore again and again
if the graphics cards doesn't support it for some reason
* disabled BScreen::WaitForRetarce() for now, since it will just
hang on ATI Radeon at least
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17266 a95241bf-73f2-0310-859d-f6bbb57e9c96
* The Decorator are temporarily using ui_color() - this needs to be changed
to use the DesktopSettings (when the decorator stuff gets refactored); right
now, the colors are fixed.
* Added B_WINDOW_TEXT_COLOR, B_WINDOW_INACTIVE_TAB_COLOR, and
B_WINDOW_INACTIVE_TEXT_COLOR to the UI colors, B_WINDOW_TAB_COLOR is no
longer deprecated. Note, however, that not every decorator may use these
colors.
* Removed unused and wrong (ie. hard-coded paths) stuff from ServerConfig.h.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17236 a95241bf-73f2-0310-859d-f6bbb57e9c96
read-only area shared between the Desktop and all applications.
* Right now, this area only contains the desktop colors, ie. B_PANEL_BACKGROUND_COLOR
etc.; ui_color() no longer needs to ask the server for these colors.
* The ui_colors are now maintained by DesktopSettings, though ColorSet is still there.
* The default colors are now hardcoded once and for everyone in InterfaceDefs.h, ie.
the app_server uses them as well.
* Desktop::Init() can now also return an error (but that is not yet accounted for).
* Cleaned up InterfaceDefs.h.
* Fixed wrong include in moreUTF8.h.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17232 a95241bf-73f2-0310-859d-f6bbb57e9c96
AGGTextRenderer (when switching the DrawState for font stuff)
* removed unused stuff from the font signature generation that
is used to synchronize the font cache
* finally nailed that bug that made glyphs of the wrong size appear
within lines of text (the problem basically was that outside code
messed with the freetype library instance while our glyph cache
thought the library was last setup by itself)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17217 a95241bf-73f2-0310-859d-f6bbb57e9c96
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
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
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
