| |||||||||||||
Not all gainNot all gainPosted Apr 11, 2012 20:35 UTC (Wed) by renox (subscriber, #23785)Parent article: LFCS 2012: X and Wayland
> resizing windows in X is currently "messy" and that causes "ugly output". But that will be fixed with Wayland
I wonder if the "ugly output" happens only with applications/toolkit slow to redraw a window or if this is not related?
I'm not sure that one is better than the other: the solution IMHO is to avoid slow redrawing with a per-window thread dedicated to the rendering like BeOS/Haiku does.
(Log in to post comments)
Not all gain Posted Apr 11, 2012 21:57 UTC (Wed) by drag (subscriber, #31333) [Link]
No I don't think forcing application developers to re-write all their applications to be multithreaded and then use a separate thread for rendering itself isn't going to solve the problem that X still forces a significant number of re-draws to resize windows. The ugliness still happens when the application isn't busy.
Not all gain Posted Apr 12, 2012 0:52 UTC (Thu) by dgm (subscriber, #49227) [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. 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).
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.
|
|||||||||||||