app_server: Remove IsDoubleBuffered() default implementation from HWInterface.

It just causes confusion and is wrong in the case where double buffering
status changed during the object lifetime.

Change-Id: Ia1a9ae3f5a1b1b7d521b79c7d1c7be92cef60a06
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4633
Reviewed-by: waddlesplash <waddlesplash@gmail.com>

app_server: do not flush back buffer outside of clipping

Introduce DrawTransaction that automatically hide/show floating overlays
and flush back buffer.

Fixes #15574.

Change-Id: I30088b74fc66cfcd5b2b433b34141e7d496f68a1
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3496
Reviewed-by: Axel Dörfler <axeld@pinc-software.de>

app_server memory management fixes: use BReference

Use BReference for more automated reference counting in app_server,
fixing some use-after-free and other problems.

Extracted from https://review.haiku-os.org/c/haiku/+/2695

Change-Id: I141bb248229405896b29feff3338447f7257b0b4
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3175
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>

app_server: some missing std::nothrow and error checks.

I had app_server crash on me because of an uncaught allocation
exception. I don't know if this will fix it but it's better to try to
survive even if it may result in some UI glitches.

Change-Id: I09dd2a7e6ff63d52f51389d7418d1a1d1810af00
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1720
Reviewed-by: waddlesplash <waddlesplash@gmail.com>

app_server: Implement screen changed hooks and notifications.

The ScreenOwner interface gets an additional ScreenChanged() hook. It
is implemented in the Desktop class to automatically set the preferred
screen mode on the changed screen.

The HWInterfaceListener, previously only used by the downstream
DrawingEngine, gets an additional ScreenChanged() hook as well to inform
an upstream client of a changed screen.

The ScreenManager ties these two mechanisms together.

Support for configuring screen backlight

Accelerant interface:
Introduce new hooks B_SET_BRIGHTNESS and B_GET_BRIGHTNESS. Brightness is
a float in the 0..1 range.

App_server:
Forward brightness things between BScreen and the accelerant.

intel_extreme:
Implement the hooks. Note that this only works for laptop panels, but
the driver will pretend to support it in other cases as well.

Screen preferences:
If the accelerant supports the B_GET_BRIGHTNESS hook, allow to set
brightness with a slider. Otherwise, the slidere is hidden and these
changes aren't visible.

Applied an updated patch by looncraz to enable hardware cursor.

I made the following changes to the original patch:
* Add const to the cursor setting functions.
* Removed the legacy cursor copying code.
* Minor coding style cleanup.

Fixed debug build.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35820 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Adding a remote desktop interface that operates on app_server drawing
primitives by providing a RemoteDrawingEngine and a RemoteHWInterface.
Not really optimized yet, still a bit WIP.
* Adding corresponding infrastructure like a blocking ring buffer and network
sender/receiver that are attached to the buffers to feed/drain them as well
as a RemoteMessage helper that provides a message based interface.
* Adding target screen concept to request an app to be run on a specific screen.
It's controlled by the TARGET_SCREEN environment variable which is added on
the app side and sent to the app_server.
* Right now only remote target screens are supported, in which case a new
RemoteHWInterface is created that tries to connect to the given host:port.
* Fix shape bounds when drawing, they need to be translated by the pen position
and converted to screen like the points as well. Wasn't visible though as the
bounds weren't used in the normal DrawingEngine.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33417 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Cleanup, no functional change.

+alphabranch


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32881 a95241bf-73f2-0310-859d-f6bbb57e9c96

To allow testing the ViewHWInterface (used in the test environment) with
both double buffering and single buffering, Invalidate() needs to be
virtual and ViewHWInterface needs to decide where to invalidate it's host
window.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28480 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Rewrote the UpdateQueue class. It actually works now and would perform screen
updates during the vertical refresh, but it causes flickering again since
there is no guarantee that screen regions will stay clean from the time that
they were scheduled with the UpdateQueue until the UpdateQueue thread
transfers them. Therefor it is still disabled.
* Refactored a bit the distinction between Invalidate() and CopyToFront().
Invalidate() used to be virtual, but now CopyToFront() is. This was mainly
needed for the app_server test environment, because the host window needs
to call Invalidate() when the front buffer bitmap is clean. When the
UpdateQueue is used, this needs to be CopyToFront(). Now the separation is
cleaner in combination with the UpdateQueue.
* Fixed a problem in HWInterface::CopyToFront(): When separating the region
outside the cursor and the region with the cursor during a transfer, it
needs to hold the fFloatingOverlay lock to make sure the cursor is not
moved in the meantime. This fixes graphics glitches with remnants of the
cursor staying on screen. These could very rarely be observed, but much more
often with the accelerated double-buffer mode.
* Enabled the accelerated double buffered mode, since it works now very well.
I was able to test it with the nVidea driver on an nVideo 7300. It works by
allocating a frame buffer twice the height of the configured screen mode.
Then all drawing goes into the offscreen portion, including accelerated
driver functions. AccelerantHWInterface::_CopyToFront() then uses acceleration
to blit the clean regions in the offscreen portion of the frame buffer into
the visible part. Please tell me if there are problems, for example when
if there is too few video memory, or if a driver does not handle it correctly.
To disable it, see src/servers/app/drawing/AccelerantHWInterface.cpp line 511.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28301 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Refactor the method that actually copies rectangles from the back buffer to
the front buffer so that derived classes could override it.
* Minor coding style changes.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26542 a95241bf-73f2-0310-859d-f6bbb57e9c96

HWInterface::Cursor() and therefor Desktop::Cursor() accessed the
current cursor without locking, and did not add a reference while
using the cursor. I have tried to solve both problems by introducing
a simple ServerCursorReference class, which makes sure that the
reference count is properly maintained. There are only two places
where this code was even used, from within ServerApp and when taking
screenshots. Axel, you mentioned in #837 that the code is unsafe, is
this what you meant? This hopefully fixes #837, but it is very hard
to reproduce in the first place, I will close the ticket, but it should
just be reopened if ever encountered again.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24741 a95241bf-73f2-0310-859d-f6bbb57e9c96

Cursor frame can be expressed using IntRect. Saves a few lines of code too.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24099 a95241bf-73f2-0310-859d-f6bbb57e9c96

* ReadBitmap() could mess up the software cursor locking, since it
used the BRect version of HideSoftwareCursor() but then called
ShowSoftwareCursor() unconditionally.
* Renamed Hide/ShowSoftwareCursor() to Hide/ShowFloatingOverlays().
* Removed no longer needed FontLocker.
* Implemented AutoFloatingOverlaysHider and got rid of a lot of
code duplication this way.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24095 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Introduced a monitor_info structure and means to let it be filled by the
accelerant (or the app_server via EDID info). It's still experimental
API, and opinions are welcome.
* Moved BPrivateScreen into the BPrivate namespace.
* Rewrote Screen.h.
* Introduced a BScreen::GetMonitorInfo() method, and implemented it in the
app server as well (ie. AS_GET_MONITOR_INFO).


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22563 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Started accelerant extension to be able to get the preferred mode from
the accelerant, as well as its EDID info. B_GET_PREFERRED_DISPLAY_MODE and
B_GET_EDID_INFO are both optional. The preferred mode will be taken from the
EDID info if only the latter hook is implemented, or the former returned an
error.
* Currently, the app_server should correctly set the preferred mode on start,
but no accelerant supports that yet, so it's not really tested.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22520 a95241bf-73f2-0310-859d-f6bbb57e9c96

Correctly implemented the missing BBitmap::GetOverlayRestrictions() on the
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

* get rid of RGBColor usage where it is not needed, this simplified many things,
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

Moved the (currently very simplistic) code to check if a display_mode is valid into
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

* Replaced DEBUG MultiLocker with an implementation that actually helps debugging
locking problems (instead of debugging the locker class).
* MultiLocker::IsReadLocked() is now only exported with DEBUG mode turned on, as
it only works correctly in this case.
* Made MultiLocker safe against B_INTERRUPTED, ie. it now just tries to lock again
instead of failing for no obvious reason.
* Removed bogus arguments to acquire_sem_etc() in MultiLocker (like B_DO_NOT_RESCHEDULE).
* Applied coding style to MultiLocker.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20055 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Moved VGA planar mode blitting into the VESA kernel driver.
* In grayscale mode, the AccelerantHWInterface now sets the palette correctly.
* HWInterface now has a fVGADevice set by AccelerantHWInterface which will be used
to talk to the VESA driver.
* Completed planar blitting for all 4 planes; we now have a perfect 16 color
grayscale mode when you choose "Standard VGA mode" in the boot loader with
an unsupported graphics card (such as in Qemu).


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19567 a95241bf-73f2-0310-859d-f6bbb57e9c96

* renamed HWInterface locking to LockParallelAccess() and
LockExclusiveAccess() (meaning more or less access to the
frame buffer)
* extracted the AGGTextRenderer to be a global instance used
by each Painter instance (currently, it is thread safe because
of the global font lock, so there is some work left in this
regard)
* gave every ServerWindow it's own DrawingEngine instance, this
is work in progress. So far, there doesn't seem to be a regression,
but less fighting over the exclusive access to the frame buffer, now
each ServerWindow thread can draw in parallel. There is room for
improvement, plus I think I'm leaking the DrawingEngine...
* changed the locking for the software cursor. ShowSoftwareCursor()
can only be called if HideSoftwareCursor(BRect) returned true, or
if you called the generic HideSoftwareCursor(), since it needs
to keep the cursor lock and unlocks in Show...!
* some clean up and renaming in Decorator and friends
* moved PatternHandler.h to live along with the .cpp


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19427 a95241bf-73f2-0310-859d-f6bbb57e9c96

* introduced a listener mechanism to be notified of frame buffer
changes in the HWInterface (ie on mode switch)
* initialization and shutdown of the HWInterface instance no longer
go through DrawingEngine, which had nothing to do with it in the
first place
(this is in preparation of giving each ServerWindow it's own
DrawingEngine instance)
* small performance improvement in ViewLayer::ScrollBy()
* some cleanup in ServerConfig.h


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19391 a95241bf-73f2-0310-859d-f6bbb57e9c96

Renamed HWInterface::GetCursorPosition() to CursorPosition() to match
the usual style.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18595 a95241bf-73f2-0310-859d-f6bbb57e9c96

Some more GCC 4 and PPC fixes.
* 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

* Accidently broke overlay (but BerliOS didn't let me commit yesterday :-/), since
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

* Some refactoring: renamed OverlayCookie to Overlay and put it in its own
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

* We now have working video overlay - even though the overlay_token handling
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

* Refined overlay support a bit: we now allow as many overlay bitmaps to be
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

Implemented some more overlay support - the overlay bitmap is now allocated
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

* implemented view bitmap options (B_BITMAP_TILE...) in
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

* Started a naive implementation of BView::SetViewCursor() server-side - doesn't
work though, as HWInterface can only draw B_RGB32 cursors...
* More build fixes for libbe_test target - it defines __HAIKU__ as well, now


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16211 a95241bf-73f2-0310-859d-f6bbb57e9c96

* I decided having the cursor obscuring feature in the HWInterface class
was not such a bad idea after all.
* Reenabled obscuring the cursor in ServerApp.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15925 a95241bf-73f2-0310-859d-f6bbb57e9c96

first simplistic implementation of drag bitmaps, drawing modes need more work, drawing text into offscreen bitmaps seems to be broken for some weird reason, B_OP_COPY actually copies the alpha value of the color as well

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15671 a95241bf-73f2-0310-859d-f6bbb57e9c96

implemented AS_GET_ACCELERANT/DRIVER_PATH and renamed the relative constants

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15666 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Prepared the BScreen and BPrivateScreen class to be used with multiple monitors.
* BPrivateScreen now buffers its frame for 0.1 seconds (so that calling it several
times in a row is both consistent and cheap).
* Added GetFrameBufferConfig() call to the HW interface (and implemented it).
* Added server commands AS_VALID_SCREEN_ID, AS_GET_NEXT_SCREEN_ID, and
AS_GET_FRAME_BUFFER_CONFIG.
* BPrivateScreen::BaseAddress() and BPrivateScreen::BytesPerRow() are now working.
* minor cleanup.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14915 a95241bf-73f2-0310-859d-f6bbb57e9c96

first step of geting rid of abstract DisplayDriver base class for less development overhead, DisplayDriverPainter is renamed to DrawingEngine

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14694 a95241bf-73f2-0310-859d-f6bbb57e9c96

tried to find the bug that causes the wrong area underneath the software cursor to be restored, but failed, the only accomplishment is that the cursor is now showing right from the beginning, not only after one moves the mouse

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@13702 a95241bf-73f2-0310-859d-f6bbb57e9c96

offscreen bitmaps work, tested on Haiku as well, supports all colorspaces that BBitmap::ImportBits() supports. It uses a fallback for non-B_RGB(A)32 bitmaps. Added support for B_SUB_PIXEL_PRECISION view flags, though it is a bit hacky, since I had to add it to LayerData, even though it is not a true part of stack data. Added Layer::SetFlags() to enforce code path and update fLayerData. Cleaned up DisplayDriverPainter and DisplayDriver API (changed some const BRect& rect to simply BRect rect in order to be able to reuse it in the code), moved Painter.h, the test environment only draws the changed part of the frame buffer again - this causes a lot less CPU overhead, Painter special cases stroke width of 1.0 to use square caps, which is similar to R5 implementation and removes a lot of problems with non-straight line drawing, ServerWindow uses the DisplayDriver from it's WinBorder instead of the one from the Desktop (needed for offscreen windows, which have their own DisplayDriverPainter), it also checks for GetRootLayer() == NULL, because offscreen layers are not attached to a RootLayer, there was a fix for scrolling which worked at least in the test environment, it is now defunced, because Adi moved _CopyBits to Layer... I need to reenable it later, LayerData has no more fEscapementDelta, also fixed fFontAliasing (which was thought to overriding the font flags, and now works as such again), Desktop initialises the menu_info and scroll_bar_info stuff, which makes ScrollBars work actually... hope I didn't forget something.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@13448 a95241bf-73f2-0310-859d-f6bbb57e9c96

implemented client/server side support for BScreen::GetDeviceInfo() and WaitForRetrace(), and (only client side) support for Bscreen::ProposeMode()

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@13266 a95241bf-73f2-0310-859d-f6bbb57e9c96

Added some root layer locking in ServerWindow.cpp when accessing the layer tree. Moved HWInterface management out of DisplayDriverPainter and into Desktop. Removed all the directly hardware related functions from DisplayDriver API. They just called the same HWInterface functions. Now DisplayDriver is much cleaner and ready for being attached to a yet to be written BitmapHWInterface. Clean up of the display mode stuff in Screen and the View-/AccelerantHWInterface. Frequency is now regarded on Haiku. AccelerantHWInterface::GetModeList now works before SetMode has been called. Added MultiLocker from the sample code. HWInterface uses it now in preparation to being used from multiple instances of DisplayDriver.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@13252 a95241bf-73f2-0310-859d-f6bbb57e9c96

Enabled HW acceleration for CopyRegion(). Tested on Haiku and it works. I also implemented FillRegion and InvertRegion. But using different acceleration hooks after one another freezes Haiku, app_server, the accelerant or whatever. I have no clue about accelerants, so if a knowledgable someone would have a look at AccelerantHWInterface.cpp, that'd be great. The software cursor stuff has a cosmetical bug with regards to CopyRegion() too, I don't understand it yet. I also tried to improve StringWidth() and DrawString() preformance. I confirmed that the glyph cache is actually used, but AGGTextRenderer::RenderString() is a dog.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12573 a95241bf-73f2-0310-859d-f6bbb57e9c96

added support for software cursor needed for single buffered mode

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12561 a95241bf-73f2-0310-859d-f6bbb57e9c96

Implemented changes necessary for single buffered mode, it is turned off for now, because the soft cursor is currently not being taken care of. We will still use double buffering if the screen color space is not 32 bits, too.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12449 a95241bf-73f2-0310-859d-f6bbb57e9c96

refactoring, speedup by decoupling back to front transferes from drawing and usage of special memcpy routine, minor speedups in Painter

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12437 a95241bf-73f2-0310-859d-f6bbb57e9c96

fixed some font related problems, Painter should now rely on the app_server font manager. maybe I fixed some compile problems too. Sorry if that was the case.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12144 a95241bf-73f2-0310-859d-f6bbb57e9c96

fixed app_server build, though I don't exactly know why that fixes it

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12130 a95241bf-73f2-0310-859d-f6bbb57e9c96

code refactoring, moved common stuff into the base class

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12129 a95241bf-73f2-0310-859d-f6bbb57e9c96

implemented cursor support in the DisplayDriverPainter

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12107 a95241bf-73f2-0310-859d-f6bbb57e9c96

moved the place of implementation of locking in DisplayDriver, because the Painter version has it elsewhere. the DisplayDriver locking API is now abstract, the same locking is now in DisplayDriverImpl, Painter version uses HWInterface for locking

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12084 a95241bf-73f2-0310-859d-f6bbb57e9c96

added DPMS functions to HWInterface as well as Initatialze and Shutdown, added a couple of TODO comments

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12058 a95241bf-73f2-0310-859d-f6bbb57e9c96

abstract base class and implementation using BView and BWindow of an interface to a graphics card, UpdateQueue doesn't work yet, it was going to be used to decouple frame buffer transfers to the front buffer from the drawing in the back buffer

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12056 a95241bf-73f2-0310-859d-f6bbb57e9c96

Applied an updated patch by looncraz to enable hardware cursor.

I made the following changes to the original patch:
* Add const to the cursor setting functions.
* Removed the legacy cursor copying code.
* Minor coding style cleanup.

Fixed debug build.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35820 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Adding a remote desktop interface that operates on app_server drawing
primitives by providing a RemoteDrawingEngine and a RemoteHWInterface.
Not really optimized yet, still a bit WIP.
* Adding corresponding infrastructure like a blocking ring buffer and network
sender/receiver that are attached to the buffers to feed/drain them as well
as a RemoteMessage helper that provides a message based interface.
* Adding target screen concept to request an app to be run on a specific screen.
It's controlled by the TARGET_SCREEN environment variable which is added on
the app side and sent to the app_server.
* Right now only remote target screens are supported, in which case a new
RemoteHWInterface is created that tries to connect to the given host:port.
* Fix shape bounds when drawing, they need to be translated by the pen position
and converted to screen like the points as well. Wasn't visible though as the
bounds weren't used in the normal DrawingEngine.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33417 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Cleanup, no functional change.

+alphabranch


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32881 a95241bf-73f2-0310-859d-f6bbb57e9c96

To allow testing the ViewHWInterface (used in the test environment) with
both double buffering and single buffering, Invalidate() needs to be
virtual and ViewHWInterface needs to decide where to invalidate it's host
window.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28480 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Rewrote the UpdateQueue class. It actually works now and would perform screen
updates during the vertical refresh, but it causes flickering again since
there is no guarantee that screen regions will stay clean from the time that
they were scheduled with the UpdateQueue until the UpdateQueue thread
transfers them. Therefor it is still disabled.
* Refactored a bit the distinction between Invalidate() and CopyToFront().
Invalidate() used to be virtual, but now CopyToFront() is. This was mainly
needed for the app_server test environment, because the host window needs
to call Invalidate() when the front buffer bitmap is clean. When the
UpdateQueue is used, this needs to be CopyToFront(). Now the separation is
cleaner in combination with the UpdateQueue.
* Fixed a problem in HWInterface::CopyToFront(): When separating the region
outside the cursor and the region with the cursor during a transfer, it
needs to hold the fFloatingOverlay lock to make sure the cursor is not
moved in the meantime. This fixes graphics glitches with remnants of the
cursor staying on screen. These could very rarely be observed, but much more
often with the accelerated double-buffer mode.
* Enabled the accelerated double buffered mode, since it works now very well.
I was able to test it with the nVidea driver on an nVideo 7300. It works by
allocating a frame buffer twice the height of the configured screen mode.
Then all drawing goes into the offscreen portion, including accelerated
driver functions. AccelerantHWInterface::_CopyToFront() then uses acceleration
to blit the clean regions in the offscreen portion of the frame buffer into
the visible part. Please tell me if there are problems, for example when
if there is too few video memory, or if a driver does not handle it correctly.
To disable it, see src/servers/app/drawing/AccelerantHWInterface.cpp line 511.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28301 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Refactor the method that actually copies rectangles from the back buffer to
the front buffer so that derived classes could override it.
* Minor coding style changes.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26542 a95241bf-73f2-0310-859d-f6bbb57e9c96

HWInterface::Cursor() and therefor Desktop::Cursor() accessed the
current cursor without locking, and did not add a reference while
using the cursor. I have tried to solve both problems by introducing
a simple ServerCursorReference class, which makes sure that the
reference count is properly maintained. There are only two places
where this code was even used, from within ServerApp and when taking
screenshots. Axel, you mentioned in #837 that the code is unsafe, is
this what you meant? This hopefully fixes #837, but it is very hard
to reproduce in the first place, I will close the ticket, but it should
just be reopened if ever encountered again.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24741 a95241bf-73f2-0310-859d-f6bbb57e9c96

Cursor frame can be expressed using IntRect. Saves a few lines of code too.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24099 a95241bf-73f2-0310-859d-f6bbb57e9c96

* ReadBitmap() could mess up the software cursor locking, since it
used the BRect version of HideSoftwareCursor() but then called
ShowSoftwareCursor() unconditionally.
* Renamed Hide/ShowSoftwareCursor() to Hide/ShowFloatingOverlays().
* Removed no longer needed FontLocker.
* Implemented AutoFloatingOverlaysHider and got rid of a lot of
code duplication this way.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24095 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Introduced a monitor_info structure and means to let it be filled by the
accelerant (or the app_server via EDID info). It's still experimental
API, and opinions are welcome.
* Moved BPrivateScreen into the BPrivate namespace.
* Rewrote Screen.h.
* Introduced a BScreen::GetMonitorInfo() method, and implemented it in the
app server as well (ie. AS_GET_MONITOR_INFO).


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22563 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Started accelerant extension to be able to get the preferred mode from
the accelerant, as well as its EDID info. B_GET_PREFERRED_DISPLAY_MODE and
B_GET_EDID_INFO are both optional. The preferred mode will be taken from the
EDID info if only the latter hook is implemented, or the former returned an
error.
* Currently, the app_server should correctly set the preferred mode on start,
but no accelerant supports that yet, so it's not really tested.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22520 a95241bf-73f2-0310-859d-f6bbb57e9c96

Correctly implemented the missing BBitmap::GetOverlayRestrictions() on the
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

* get rid of RGBColor usage where it is not needed, this simplified many things,
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

Moved the (currently very simplistic) code to check if a display_mode is valid into
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

* Replaced DEBUG MultiLocker with an implementation that actually helps debugging
locking problems (instead of debugging the locker class).
* MultiLocker::IsReadLocked() is now only exported with DEBUG mode turned on, as
it only works correctly in this case.
* Made MultiLocker safe against B_INTERRUPTED, ie. it now just tries to lock again
instead of failing for no obvious reason.
* Removed bogus arguments to acquire_sem_etc() in MultiLocker (like B_DO_NOT_RESCHEDULE).
* Applied coding style to MultiLocker.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20055 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Moved VGA planar mode blitting into the VESA kernel driver.
* In grayscale mode, the AccelerantHWInterface now sets the palette correctly.
* HWInterface now has a fVGADevice set by AccelerantHWInterface which will be used
to talk to the VESA driver.
* Completed planar blitting for all 4 planes; we now have a perfect 16 color
grayscale mode when you choose "Standard VGA mode" in the boot loader with
an unsupported graphics card (such as in Qemu).


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19567 a95241bf-73f2-0310-859d-f6bbb57e9c96

* renamed HWInterface locking to LockParallelAccess() and
LockExclusiveAccess() (meaning more or less access to the
frame buffer)
* extracted the AGGTextRenderer to be a global instance used
by each Painter instance (currently, it is thread safe because
of the global font lock, so there is some work left in this
regard)
* gave every ServerWindow it's own DrawingEngine instance, this
is work in progress. So far, there doesn't seem to be a regression,
but less fighting over the exclusive access to the frame buffer, now
each ServerWindow thread can draw in parallel. There is room for
improvement, plus I think I'm leaking the DrawingEngine...
* changed the locking for the software cursor. ShowSoftwareCursor()
can only be called if HideSoftwareCursor(BRect) returned true, or
if you called the generic HideSoftwareCursor(), since it needs
to keep the cursor lock and unlocks in Show...!
* some clean up and renaming in Decorator and friends
* moved PatternHandler.h to live along with the .cpp


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19427 a95241bf-73f2-0310-859d-f6bbb57e9c96

* introduced a listener mechanism to be notified of frame buffer
changes in the HWInterface (ie on mode switch)
* initialization and shutdown of the HWInterface instance no longer
go through DrawingEngine, which had nothing to do with it in the
first place
(this is in preparation of giving each ServerWindow it's own
DrawingEngine instance)
* small performance improvement in ViewLayer::ScrollBy()
* some cleanup in ServerConfig.h


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19391 a95241bf-73f2-0310-859d-f6bbb57e9c96

Renamed HWInterface::GetCursorPosition() to CursorPosition() to match
the usual style.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18595 a95241bf-73f2-0310-859d-f6bbb57e9c96

Some more GCC 4 and PPC fixes.
* 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

* Accidently broke overlay (but BerliOS didn't let me commit yesterday :-/), since
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

* Some refactoring: renamed OverlayCookie to Overlay and put it in its own
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

* We now have working video overlay - even though the overlay_token handling
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

* Refined overlay support a bit: we now allow as many overlay bitmaps to be
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

Implemented some more overlay support - the overlay bitmap is now allocated
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

* implemented view bitmap options (B_BITMAP_TILE...) in
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

* Started a naive implementation of BView::SetViewCursor() server-side - doesn't
work though, as HWInterface can only draw B_RGB32 cursors...
* More build fixes for libbe_test target - it defines __HAIKU__ as well, now


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16211 a95241bf-73f2-0310-859d-f6bbb57e9c96

* I decided having the cursor obscuring feature in the HWInterface class
was not such a bad idea after all.
* Reenabled obscuring the cursor in ServerApp.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15925 a95241bf-73f2-0310-859d-f6bbb57e9c96

first simplistic implementation of drag bitmaps, drawing modes need more work, drawing text into offscreen bitmaps seems to be broken for some weird reason, B_OP_COPY actually copies the alpha value of the color as well

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15671 a95241bf-73f2-0310-859d-f6bbb57e9c96

implemented AS_GET_ACCELERANT/DRIVER_PATH and renamed the relative constants

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15666 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Prepared the BScreen and BPrivateScreen class to be used with multiple monitors.
* BPrivateScreen now buffers its frame for 0.1 seconds (so that calling it several
times in a row is both consistent and cheap).
* Added GetFrameBufferConfig() call to the HW interface (and implemented it).
* Added server commands AS_VALID_SCREEN_ID, AS_GET_NEXT_SCREEN_ID, and
AS_GET_FRAME_BUFFER_CONFIG.
* BPrivateScreen::BaseAddress() and BPrivateScreen::BytesPerRow() are now working.
* minor cleanup.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14915 a95241bf-73f2-0310-859d-f6bbb57e9c96

first step of geting rid of abstract DisplayDriver base class for less development overhead, DisplayDriverPainter is renamed to DrawingEngine

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14694 a95241bf-73f2-0310-859d-f6bbb57e9c96

tried to find the bug that causes the wrong area underneath the software cursor to be restored, but failed, the only accomplishment is that the cursor is now showing right from the beginning, not only after one moves the mouse

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@13702 a95241bf-73f2-0310-859d-f6bbb57e9c96

offscreen bitmaps work, tested on Haiku as well, supports all colorspaces that BBitmap::ImportBits() supports. It uses a fallback for non-B_RGB(A)32 bitmaps. Added support for B_SUB_PIXEL_PRECISION view flags, though it is a bit hacky, since I had to add it to LayerData, even though it is not a true part of stack data. Added Layer::SetFlags() to enforce code path and update fLayerData. Cleaned up DisplayDriverPainter and DisplayDriver API (changed some const BRect& rect to simply BRect rect in order to be able to reuse it in the code), moved Painter.h, the test environment only draws the changed part of the frame buffer again - this causes a lot less CPU overhead, Painter special cases stroke width of 1.0 to use square caps, which is similar to R5 implementation and removes a lot of problems with non-straight line drawing, ServerWindow uses the DisplayDriver from it's WinBorder instead of the one from the Desktop (needed for offscreen windows, which have their own DisplayDriverPainter), it also checks for GetRootLayer() == NULL, because offscreen layers are not attached to a RootLayer, there was a fix for scrolling which worked at least in the test environment, it is now defunced, because Adi moved _CopyBits to Layer... I need to reenable it later, LayerData has no more fEscapementDelta, also fixed fFontAliasing (which was thought to overriding the font flags, and now works as such again), Desktop initialises the menu_info and scroll_bar_info stuff, which makes ScrollBars work actually... hope I didn't forget something.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@13448 a95241bf-73f2-0310-859d-f6bbb57e9c96

implemented client/server side support for BScreen::GetDeviceInfo() and WaitForRetrace(), and (only client side) support for Bscreen::ProposeMode()

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@13266 a95241bf-73f2-0310-859d-f6bbb57e9c96

Added some root layer locking in ServerWindow.cpp when accessing the layer tree. Moved HWInterface management out of DisplayDriverPainter and into Desktop. Removed all the directly hardware related functions from DisplayDriver API. They just called the same HWInterface functions. Now DisplayDriver is much cleaner and ready for being attached to a yet to be written BitmapHWInterface. Clean up of the display mode stuff in Screen and the View-/AccelerantHWInterface. Frequency is now regarded on Haiku. AccelerantHWInterface::GetModeList now works before SetMode has been called. Added MultiLocker from the sample code. HWInterface uses it now in preparation to being used from multiple instances of DisplayDriver.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@13252 a95241bf-73f2-0310-859d-f6bbb57e9c96

Enabled HW acceleration for CopyRegion(). Tested on Haiku and it works. I also implemented FillRegion and InvertRegion. But using different acceleration hooks after one another freezes Haiku, app_server, the accelerant or whatever. I have no clue about accelerants, so if a knowledgable someone would have a look at AccelerantHWInterface.cpp, that'd be great. The software cursor stuff has a cosmetical bug with regards to CopyRegion() too, I don't understand it yet. I also tried to improve StringWidth() and DrawString() preformance. I confirmed that the glyph cache is actually used, but AGGTextRenderer::RenderString() is a dog.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12573 a95241bf-73f2-0310-859d-f6bbb57e9c96

added support for software cursor needed for single buffered mode

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12561 a95241bf-73f2-0310-859d-f6bbb57e9c96

Implemented changes necessary for single buffered mode, it is turned off for now, because the soft cursor is currently not being taken care of. We will still use double buffering if the screen color space is not 32 bits, too.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12449 a95241bf-73f2-0310-859d-f6bbb57e9c96

refactoring, speedup by decoupling back to front transferes from drawing and usage of special memcpy routine, minor speedups in Painter

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12437 a95241bf-73f2-0310-859d-f6bbb57e9c96

fixed some font related problems, Painter should now rely on the app_server font manager. maybe I fixed some compile problems too. Sorry if that was the case.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12144 a95241bf-73f2-0310-859d-f6bbb57e9c96

fixed app_server build, though I don't exactly know why that fixes it

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12130 a95241bf-73f2-0310-859d-f6bbb57e9c96

code refactoring, moved common stuff into the base class

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12129 a95241bf-73f2-0310-859d-f6bbb57e9c96

implemented cursor support in the DisplayDriverPainter

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12107 a95241bf-73f2-0310-859d-f6bbb57e9c96

moved the place of implementation of locking in DisplayDriver, because the Painter version has it elsewhere. the DisplayDriver locking API is now abstract, the same locking is now in DisplayDriverImpl, Painter version uses HWInterface for locking

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12084 a95241bf-73f2-0310-859d-f6bbb57e9c96

added DPMS functions to HWInterface as well as Initatialze and Shutdown, added a couple of TODO comments

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12058 a95241bf-73f2-0310-859d-f6bbb57e9c96

abstract base class and implementation using BView and BWindow of an interface to a graphics card, UpdateQueue doesn't work yet, it was going to be used to decouple frame buffer transfers to the front buffer from the drawing in the back buffer

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12056 a95241bf-73f2-0310-859d-f6bbb57e9c96