| |||||||||||||
Not all gainNot all gainPosted Apr 12, 2012 0:52 UTC (Thu) by dgm (subscriber, #49227)In reply to: Not all gain by renox Parent article: LFCS 2012: X and Wayland
There's no need to "stutter". Weston can use OpenGL to stretch current window contents if the application cannot provide a new buffer on time. This is a better solution than Haiku IMHO, because you do not show half painted windows and can be hardware accelerated.
Rendering in a thread doesn't make drawing code magically faster. It only solves the problem of the application missing the retrace deadline because it's busy doing actual work, at the price of doing less such work (the thread needs cycles to draw the window, too).
(Log in to post comments)
Not all gain Posted Apr 12, 2012 5:38 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
>There's no need to "stutter". Weston can use OpenGL to stretch current window contents if the application cannot provide a new buffer on time.
I tried that some years ago. It looks extremely ugly.
It's much better to simply draw an empty overlay rectangle showing the future window's size.
Not all gain Posted Apr 12, 2012 7:41 UTC (Thu) by renox (subscriber, #23785) [Link]
> There's no need to "stutter". Weston can use OpenGL to stretch current window contents if the application cannot provide a new buffer on time.
It depends: with client-side decoration only the client know that the mouse action is supposed to trigger a window resizing not the server.
But the client could tell the server: using two requests 'my future window size is X,Y' and 'the content is here' instead of one 'draw this buffer of size X,Y', so if the second request is slow to come then the server can do some corrective action as you say.
|
|||||||||||||