| |||||||||||||
Wayland and Weston 1.0 releasedWayland and Weston 1.0 releasedPosted Oct 26, 2012 9:04 UTC (Fri) by daniels (subscriber, #16193)In reply to: Wayland and Weston 1.0 released by renox Parent article: Wayland and Weston 1.0 released
With client-side decorations, the client sends exactly one buffer to the server - the complete window - every time it resizes.
With server-side decorations, every time the window's resized, the server has to create and fill a new buffer with the frame, then do a stretch blit (or fill the undefined contents with a solid colour, or whatever) of the contents into the frame window. Asynchronously, the contents are updated and the updated contents are blitted back into the frame. Aside from the waste of resources from the additional buffer, I believe it looks measurably worse. The 'spasm' as you get the frame changing size, followed by the content being stretched, followed by resized content (quite possibly from an old resize event, so just beign differently stretched) is pretty horrific.
Additionally, if your problem is resource starvation such that the client can't keep up, adding additional load in the form of the server drawing decorations for sizes the client's never likely to make, and the extra resource load from the additional blits, exacerbates the problem.
I'd much rather just have the pointer lagging a little behind.
(Log in to post comments)
Wayland and Weston 1.0 released Posted Oct 26, 2012 9:33 UTC (Fri) by renox (subscriber, #23785) [Link]
>Additionally, if your problem is resource starvation such that the client can't keep up,
This isn't the only reason why clients cannot keep up: applications do many thing, so if you don't dedicate a thread to the GUI, a client can be slow to answer even if the system isn't loaded.
>I'd much rather just have the pointer lagging a little behind.
It's a matter of personal preference, I don't!
Wayland and Weston 1.0 released Posted Oct 26, 2012 10:00 UTC (Fri) by daniels (subscriber, #16193) [Link]
Also, the other other reason is that it significantly complicates event handling, and creates absolutely nightmarish corner cases. Client-side decorations have the nice property of ensuring that windows actually have a single defined size, rather than size being some kind of mystical transient property that's likely to have changed by the time you submit your request.
Wayland and Weston 1.0 released Posted Oct 26, 2012 11:36 UTC (Fri) by renox (subscriber, #23785) [Link]
Oh, there is no question that client-side decorations have benefits.
But there is still this issue of jerkiness when the client is busy and even with a dedicated GUI thread the client may become busy if for example the client use a non-realtime GC (most of the GCs are not real-time), etc.
Loosing smooth resizing of windows is a HIGH price to pay for the benefits of CSD.
Wayland and Weston 1.0 released Posted Oct 26, 2012 11:47 UTC (Fri) by daniels (subscriber, #16193) [Link]
It's not smooth. Your app goes from actual rendered content -> scaled content -> scaled content -> scaled content -> actual rendered content -> scaled content -> scaled content -> actual rendered content. Imagine an app with a status bar, where you're enlarging the size: your status bar goes from its natural size with sharp fonts, to bigger and blurry, to bigger and blurry again, back to its natural size with sharp fonts, and so on, and so forth. It's a disaster for text, where you see the exact same thing, except even more jarring because the text is likely to get reflowed.
The rapid spasming transition is really, really jarring, and objectively speaking, the scaled content looks worse than genuine client-rendered content. All this is in direct conflict with Wayland's core ethos of 'every frame is perfect'.
So it's either that, or you can leave the window contents in place at the last size the client gave you, and track the new size with an outline. Which is 100% possible to implement within Wayland.
The only benefit it has is the frame window following the pointer.
(And hey, if it forces app authors to actually think about making their clients more responsive to user interaction, that's no bad thing at all.)
Wayland and Weston 1.0 released Posted Oct 26, 2012 12:33 UTC (Fri) by renox (subscriber, #23785) [Link]
>It's not smooth.[cut]
*Sigh*, at the beginning of the discussion I said 'with server side decoration the window will resize smoothly but the content of the window will be "ugly"' so I know..
>objectively speaking, the scaled content looks worse than genuine client-rendered content
And "objectively speaking" having the frame of the window resize smoothly all the time is better than resizing jerkily when the application is slow to answer to events.
I don't read the text of my windows while I'm resizing them, that why I care more about smooth resizing of the windows frame than having a nice content inside, that is a *trade-off* you prefer one option I prefer the other, that's all.
>And hey, if it forces app authors to actually think about making their clients more responsive to user interaction, that's no bad thing at all.
I actually agree with that, but as I've already said it's not easy at all, especially if you use a GC!
Wayland and Weston 1.0 released Posted Oct 26, 2012 16:05 UTC (Fri) by raven667 (subscriber, #5198) [Link]
> So it's either that, or you can leave the window contents in place at the last size the client gave you, and track the new size with an outline. Which is 100% possible to implement within Wayland.
This also seems to cover the use case you are looking for, similar to how some older WMs worked.
Wayland and Weston 1.0 released Posted Oct 26, 2012 16:30 UTC (Fri) by renox (subscriber, #23785) [Link]
>> So it's either that, or you can leave the window contents in place at the last size the client gave you, and track the new size with an outline. Which is 100% possible to implement within Wayland.
> This also seems to cover the use case you are looking for, similar to how some older WMs worked.
Not really, you loose information about how your window will look when resized which is annoying, but I think that this configuration is the best when you're using remote applications on high latency communications, so it's still an interesting configuration.
Wayland and Weston 1.0 released Posted Oct 26, 2012 16:32 UTC (Fri) by daniels (subscriber, #16193) [Link]
> Not really, you loose information about how your window will look when resized
Which you also lose whilst scaling.
Wayland and Weston 1.0 released Posted Oct 26, 2012 18:02 UTC (Fri) by renox (subscriber, #23785) [Link]
>> Not really, you loose information about how your window will look when resized
>Which you also lose whilst scaling.
Which are very temporary, short situations.
Wayland and Weston 1.0 released Posted Oct 26, 2012 18:37 UTC (Fri) by daniels (subscriber, #16193) [Link]
> Which are very temporary, short situations.
Equally as temporary and short as for client-side decorations. Although I still maintain CSDs are likely to be even more responsive for the reasons I listed above.
|
|||||||||||||