Originally posted by Teho
View Post
Announcement
Collapse
No announcement yet.
Wayland 1.0 Stable Release Is Imminent
Collapse
X
-
-
Originally posted by smitty3268 View PostIf you watch the Wayland demo, they show handling an app that is stalled. Clicking/dragging anywhere on the window to move it around. Wayland detects when the app is no longer responding, and can provide custom behaviours for that case, which would allow popping up a menu, or shrinking/expanding the window size if that is what you want to do.
As the composer can do anything in composing a frame, the client side decoration won't be a problem.
Leave a comment:
-
Originally posted by smitty3268 View PostIf you watch the Wayland demo, they show handling an app that is stalled.
Resizing/moving such application with client side management of decoration (Weston) will feel slow/jerky,
but it wouldn't with server side management of decoration even though the content of a window could become a little garbled when resizing.
Leave a comment:
-
Originally posted by renox View PostI totally disagree: I prefer responsiveness over prettiness.
When there is a separated window manager, if the application becomes busy, you can still draw the window outlines so the resizing still feel responsive (even if the content of the window becomes ugly),
, with Weston this won't be the case, the window will freeze resizing until the application answer again..
The only way to have both is to ensure that the application is never busy by using multithreading, very,very nice when you have it but a big change.
And what about moving windows?
Here, client side management of decorations looks even worse compared to server side management of decoration (except when the application is multithreaded)!
Leave a comment:
-
Originally posted by daniels View PostIt's not 100%, since there is no acceptable solution to 'my app doesn't respond quickly to resize requests', but vastly better than before.
When there is a separated window manager, if the application becomes busy, you can still draw the window outlines so the resizing still feel responsive (even if the content of the window becomes ugly),
, with Weston this won't be the case, the window will freeze resizing until the application answer again..
The only way to have both is to ensure that the application is never busy by using multithreading, very,very nice when you have it but a big change.
And what about moving windows?
Here, client side management of decorations looks even worse compared to server side management of decoration (except when the application is multithreaded)!
Leave a comment:
-
Originally posted by renox View PostFix it? With Weston, when you click on a window to resize/move it, the click event is sent to the application which then decides whether it is a resize or move action and send the corresponding command to Weston. So if the application is slow for whatever reason the moves/resizing will be jerky/laggy..
I wouldn't call this a fix, it's a trade-off!
The Wayland model is that the app tells the compositor to initiate a resize sequence, at which point the compositor just starts feeding the app resize events as appropriate. The then app sends the window with decorations already drawn, which is always safe to draw on screen. We've cut out a huge amount of the round trips and lag inherent in the X11 model, where the server would send a pointer update to the client, who would request a resize from the server, which would ask the WM what it thought; the WM would then paint a new frame and resize both its frame window and the real client window; the server notifies the app of a resize, at which point the app can finally draw its content. I left out all the app -> X server -> WM -> X server -> app roundtrips for synchronisation through window properties too - it looks even worse if you add those in.
So yeah, I maintain that the problem's solved as well as it could be.
Leave a comment:
-
Wishful thinking..
Originally posted by daniels View PostThey really are tho. Especially during resize, the app → X server → window manager → X server → app → X server dance for resizing makes that a disaster: merging the WM/compositor into the display server and introducing client-side decorations directly fixes that.
I wouldn't call this a fix, it's a trade-off!
Leave a comment:
-
Originally posted by pingufunkybeat View PostIn terms of production environment, Wayland isn't used anywhere yet, so yes, it's pretty much a research project right now. With potential to become the next standard, yes. But we're a long way off from that.
Leave a comment:
-
Originally posted by curaga View PostHalf of those things aren't X's faults. It's quite unfair to blame it for problems in something else.
X is wildly, wildly inappropriate for modern toolkits. It does kinda-sorta work, but we're (ab)using it in a way that's totally contrary to what it was designed for, and it really shows.Last edited by daniels; 23 September 2012, 07:42 PM.
Leave a comment:
-
Some of you are treating the "research project" label as some sort of grave insult, and no such insult was intended.
IMHO, it is a research project with potential to become a new standard in the future. Either in its current specification, or as a new one which learned from it.
Leave a comment:
Leave a comment: