* 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

* 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

Assigned names to "some BLocker"s to aid debugging.
Small cleanup.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14703 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

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

more correct implementation, but still exhibits problems, usage turned off in ViewHWInterface::Invalidate

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12088 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

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

* 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

* 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

Assigned names to "some BLocker"s to aid debugging.
Small cleanup.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14703 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

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

more correct implementation, but still exhibits problems, usage turned off in ViewHWInterface::Invalidate

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12088 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

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