Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
PostgreSQL 9.3 beta: Federated databases and more
LWN.net Weekly Edition for May 9, 2013
(Nearly) full tickless operation in 3.10
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!
Plus I don't think that the pointer will lag behind, only that the window won't resize smoothly, I have to look at the sources.
Wayland and Weston 1.0 released
Posted Oct 26, 2012 10:00 UTC (Fri) by daniels (subscriber, #16193)
Posted Oct 26, 2012 11:36 UTC (Fri) by renox (subscriber, #23785)
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.
Posted Oct 26, 2012 11:47 UTC (Fri) by daniels (subscriber, #16193)
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.)
Posted Oct 26, 2012 12:33 UTC (Fri) by renox (subscriber, #23785)
*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!
Posted Oct 26, 2012 16:05 UTC (Fri) by raven667 (subscriber, #5198)
This also seems to cover the use case you are looking for, similar to how some older WMs worked.
Posted Oct 26, 2012 16:30 UTC (Fri) by renox (subscriber, #23785)
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.
Posted Oct 26, 2012 16:32 UTC (Fri) by daniels (subscriber, #16193)
Which you also lose whilst scaling.
Posted Oct 26, 2012 18:02 UTC (Fri) by renox (subscriber, #23785)
Which are very temporary, short situations.
Posted Oct 26, 2012 18:37 UTC (Fri) by daniels (subscriber, #16193)
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.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds