History log of /haiku/src/servers/app/drawing/DWindowBuffer.cpp
Revision Date Author Comments
# 62b965a6 10-Dec-2005 Stephan Aßmus <superstippi@gmx.de>

* got the "cloned accelerant" based DWindowHWInterface to work, though without
using the clipping info from a BDirectWindow... I made it so that the window
used stays on top always, until I can think of something better. The other
problem is that you should not move the window, since Painter doesn't update
it's pointer into the frame buffer.
* Now the test environment is running at pretty much the same speed as it would
under Haiku, completely by-passing the BeOS app_server. It shows that Painter
needs to be optimized for writing to graphics memory, and also that we need to
figure out a way to distribute update sessions more equally. What happens is
this: The first invalidation of a window triggers an update on the client
side... the client cannot keep up with drawing, since it is pretty much
blocked all the time because the desktop thread moves a window and because
the clipping constantly changes. In the meantime, new update request are
added to the pending session because the client has still not finished with
the current session. Only when things settle a bit, the next update session
can be startet. On the bright side of things, the earlier problems with
scrolling seem to be fixed for good.
* some documentation updates on Painter


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


# 17a4024c 10-Dec-2005 Stephan Aßmus <superstippi@gmx.de>

classes needed for the new cloned Accelerant based test environment

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


# 62b965a65f1c2e5898e0ec2c294b3d5a24f7761e 10-Dec-2005 Stephan Aßmus <superstippi@gmx.de>

* got the "cloned accelerant" based DWindowHWInterface to work, though without
using the clipping info from a BDirectWindow... I made it so that the window
used stays on top always, until I can think of something better. The other
problem is that you should not move the window, since Painter doesn't update
it's pointer into the frame buffer.
* Now the test environment is running at pretty much the same speed as it would
under Haiku, completely by-passing the BeOS app_server. It shows that Painter
needs to be optimized for writing to graphics memory, and also that we need to
figure out a way to distribute update sessions more equally. What happens is
this: The first invalidation of a window triggers an update on the client
side... the client cannot keep up with drawing, since it is pretty much
blocked all the time because the desktop thread moves a window and because
the clipping constantly changes. In the meantime, new update request are
added to the pending session because the client has still not finished with
the current session. Only when things settle a bit, the next update session
can be startet. On the bright side of things, the earlier problems with
scrolling seem to be fixed for good.
* some documentation updates on Painter


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


# 17a4024ca9e730cafb989660625cbaffc663a574 10-Dec-2005 Stephan Aßmus <superstippi@gmx.de>

classes needed for the new cloned Accelerant based test environment

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