62b965a65f
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 |
||
|---|---|---|
| .. | ||
| app | ||
| debug | ||
| input | ||
| net | ||
| registrar | ||
| Jamfile | ||