/haiku/src/servers/app/drawing/ |
H A D | UpdateQueue.h | 2469a6f4272b43fb04e11290808216f6a7610599 Thu Oct 23 17:15:39 UTC 2008 Stephan Aßmus <superstippi@gmx.de> * 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
|
H A D | UpdateQueue.cpp | 2469a6f4272b43fb04e11290808216f6a7610599 Thu Oct 23 17:15:39 UTC 2008 Stephan Aßmus <superstippi@gmx.de> * 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
|
H A D | BitmapHWInterface.cpp | 2469a6f4272b43fb04e11290808216f6a7610599 Thu Oct 23 17:15:39 UTC 2008 Stephan Aßmus <superstippi@gmx.de> * 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
|
H A D | HWInterface.h | 2469a6f4272b43fb04e11290808216f6a7610599 Thu Oct 23 17:15:39 UTC 2008 Stephan Aßmus <superstippi@gmx.de> * 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
|
H A D | HWInterface.cpp | 2469a6f4272b43fb04e11290808216f6a7610599 Thu Oct 23 17:15:39 UTC 2008 Stephan Aßmus <superstippi@gmx.de> * 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
|