Re: Wayland Window Management Proposal
On 19/05/11 04:17, Bill Spitzak wrote: Michal Suchanek wrote: In the case of a resize event the response includes submitting a buffer containing resized window content to the compositor. The compositor requires this new resized content to draw the window so it cannot be avoided. I think the concern was when a client decided that the current window size is correct. This can happen if the window is not resizable, or size limits or increments or anything else cause the requested size to be rounded to the same size as it is currently. I think there is also a problem in that the compositor cannot be absolutely certain that a given resize is in response to a resize request. What I was proposing is that there is a clear "echo" of all events back to the compositor, so the compositor can know that event has been handled by the client. This would be sent after the resizing, or sent by itself if the client decided not to resize. Echos can be consolidated. An echo saying a given event was handled would also indicate that all earlier events were handled. This is necessary to make it easier to write clients that want to consolidate incoming events, for instance to only handle the last of a whole string of resize requests. The echo can also indicate that the client explicitly did not handle an event and it wants the compoitor to do so. This can allow reuse of the compositor locked-client window handling by normal clients. It also would allow clients to indicate ignored keystrokes so the compositor can do something with them, allowing a lot more global shortcut possibilities. In case of mouse-click events in the titlebar for a resize, if the client then tells the window server to resize the window, then no echo event is needed because the server now knows the client is still active. If the client doesn't want to resize, then it could send an echo, or else just request a resize using the current size. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Wayland Window Management Proposal
El dc 18 de 05 de 2011 a les 11:17 -0700, en/na Bill Spitzak va escriure: > Michal Suchanek wrote: > > [...] I think there is also a > problem in that the compositor cannot be absolutely certain that a given > resize is in response to a resize request. It doesn't need to, as it makes no difference which request (if any) triggered a resize. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Wayland Window Management Proposal
Michal Suchanek wrote: In the case of a resize event the response includes submitting a buffer containing resized window content to the compositor. The compositor requires this new resized content to draw the window so it cannot be avoided. I think the concern was when a client decided that the current window size is correct. This can happen if the window is not resizable, or size limits or increments or anything else cause the requested size to be rounded to the same size as it is currently. I think there is also a problem in that the compositor cannot be absolutely certain that a given resize is in response to a resize request. What I was proposing is that there is a clear "echo" of all events back to the compositor, so the compositor can know that event has been handled by the client. This would be sent after the resizing, or sent by itself if the client decided not to resize. Echos can be consolidated. An echo saying a given event was handled would also indicate that all earlier events were handled. This is necessary to make it easier to write clients that want to consolidate incoming events, for instance to only handle the last of a whole string of resize requests. The echo can also indicate that the client explicitly did not handle an event and it wants the compoitor to do so. This can allow reuse of the compositor locked-client window handling by normal clients. It also would allow clients to indicate ignored keystrokes so the compositor can do something with them, allowing a lot more global shortcut possibilities. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Wayland Window Management Proposal
On 17 May 2011 18:01, Sam Spilsbury wrote: >> I think the wayland compositor could track how long the clients take to >> respond to events. They would only disable if they suddenly took several >> times longer than before. If the recorded lag exceeds a threshold the >> compositor could resort to rubber-band resize. > > What is a "response to an event"? > > Avoiding a system where clients are making needless communication with > the compositor all the time just so that you can implement a fall-back > policy when client-side policy doesn't work would probably be a good > thing. In the case of a resize event the response includes submitting a buffer containing resized window content to the compositor. The compositor requires this new resized content to draw the window so it cannot be avoided. Thanks Michal ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Wayland Window Management Proposal
> I think the wayland compositor could track how long the clients take to > respond to events. They would only disable if they suddenly took several > times longer than before. If the recorded lag exceeds a threshold the > compositor could resort to rubber-band resize. What is a "response to an event"? Avoiding a system where clients are making needless communication with the compositor all the time just so that you can implement a fall-back policy when client-side policy doesn't work would probably be a good thing. > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > -- Sam Spilsbury ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Wayland Window Management Proposal
On 16 May 2011 23:13, Bill Spitzak wrote: > Michal Suchanek wrote: > >> The thing is that in Wayland the server is not aware of any remote vs >> local windows. Remote applications are in no way part of the protocol >> and will supposedly sneak in later by means of some remoting proxy. > > My understanding is the exact opposite: the compositor is *VERY* aware of > remote windows, as it is it's job to do the remoting. A client connects to a Then point me to any place where it does any remoting. > remoting wayland compositor, which sends the window contents and update What is this "remoting compositor"? A proxy that allows remote clients to connect to Wayland on other system? > information to the real wayland compositor on the remote machine. The real > one knows how to communicate with the remoting compositor. The proxy is just a plain client, how does the local Wayland tell it's a proxy? > >> As a technical detail since vrefresh is the point when the screen >> should be updated, it typically happens 50-60times per second and >> seemingly smooth movement requires about 25fps at the very least the >> timeout for the compositor to start drawing some replacement should be >> at most some 2-3 vrefresh intervals. This is something that can be >> communicated to the client so that it is well aware when it lags. > > My tests show that update can be much slower than this and still appear > "smooth". The important thing is that the contents update in exact lock-step > with the border and never flash, but rates as slow as 5fps look quite > smooth. This can be seen in some X media players that do both double > buffering and client-side decoration. It is still in the same ballpark - fractions of second. And would probably depend on the user. > >> The client, however, must communicate to the wayland window manager >> the resizability of its window so that the windowmanager can tell >> apart clients that lag and clients that plain refuse to resize because >> they rely on the window being fixed size (yuck). > > The Wayland client will send an indication that it responded to the resize > request, so the compositor will know this happened, even if the client > decided not to change the window size. It is also the client's > responsibility to initiate the resize, so it can just skip this if it knows > it is not resizable. > >> If the replacement is the last window content stretched to the new >> size and slightly blurred then the distortion might not be noticable >> even for clients that take slightly longer but not too long. For even >> less cooperative clients the "rubberband" or full window with some >> generic "stoned" image would be required. There is room for user >> preferences here for sure. > > Comparing compiz and old X, this looks worse to me. It looks best to just > have all the new window area contain whatever pixels were there before (ie > the intersection of the old and new window, surrounded by pixels from other > windows, old window borders, etc). The reason is that the pixels only change > once, from old contents to new contents. Putting anything else there makes > them change twice, from old to temporary to new contents. And what's the problem if the difference between the replacement content and the actual content is small and very unlikely to be noticed? Anyway, there is not only look but also feel of the environment. You are obsessed with the window looking pixel-correct. However, for the feel to be smooth the window must quickly react to user action. If mouse resizes are implemented this is one of the few places where many user actions happen in quick succession. The drag action results in lots of small resizes and all of these have to happen fast. Otherwise the UI appears laggy or worse, the user gets lost because the screen content does not correspond to the actual state - window sizes. > >>> On the other hand, some apps always lag behind and probably should be >>> allowed to do so if they are very important to the user. The question >>> is how. Possibly this could be *configured* via a special effect-plugin >>> that manages single or all windows different to the default setting. >>> This is like *theme'ing* those problematic issues ;) At least it allows >>> the server to follow a strict default mode without forbidding the user >>> to decide differently... > > I think the wayland compositor could track how long the clients take to > respond to events. They would only disable if they suddenly took several > times longer than before. If the recorded lag exceeds a threshold the > compositor could resort to rubber-band resize. > No way. This must be a hard limit on the compositor side so that the UI works reasonably at all times. It should be configurable by the user but not the client applications. Thanks Michal ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Wayland Window Management Proposal
Michal Suchanek wrote: The thing is that in Wayland the server is not aware of any remote vs local windows. Remote applications are in no way part of the protocol and will supposedly sneak in later by means of some remoting proxy. My understanding is the exact opposite: the compositor is *VERY* aware of remote windows, as it is it's job to do the remoting. A client connects to a remoting wayland compositor, which sends the window contents and update information to the real wayland compositor on the remote machine. The real one knows how to communicate with the remoting compositor. As a technical detail since vrefresh is the point when the screen should be updated, it typically happens 50-60times per second and seemingly smooth movement requires about 25fps at the very least the timeout for the compositor to start drawing some replacement should be at most some 2-3 vrefresh intervals. This is something that can be communicated to the client so that it is well aware when it lags. My tests show that update can be much slower than this and still appear "smooth". The important thing is that the contents update in exact lock-step with the border and never flash, but rates as slow as 5fps look quite smooth. This can be seen in some X media players that do both double buffering and client-side decoration. The client, however, must communicate to the wayland window manager the resizability of its window so that the windowmanager can tell apart clients that lag and clients that plain refuse to resize because they rely on the window being fixed size (yuck). The Wayland client will send an indication that it responded to the resize request, so the compositor will know this happened, even if the client decided not to change the window size. It is also the client's responsibility to initiate the resize, so it can just skip this if it knows it is not resizable. If the replacement is the last window content stretched to the new size and slightly blurred then the distortion might not be noticable even for clients that take slightly longer but not too long. For even less cooperative clients the "rubberband" or full window with some generic "stoned" image would be required. There is room for user preferences here for sure. Comparing compiz and old X, this looks worse to me. It looks best to just have all the new window area contain whatever pixels were there before (ie the intersection of the old and new window, surrounded by pixels from other windows, old window borders, etc). The reason is that the pixels only change once, from old contents to new contents. Putting anything else there makes them change twice, from old to temporary to new contents. On the other hand, some apps always lag behind and probably should be allowed to do so if they are very important to the user. The question is how. Possibly this could be *configured* via a special effect-plugin that manages single or all windows different to the default setting. This is like *theme'ing* those problematic issues ;) At least it allows the server to follow a strict default mode without forbidding the user to decide differently... I think the wayland compositor could track how long the clients take to respond to events. They would only disable if they suddenly took several times longer than before. If the recorded lag exceeds a threshold the compositor could resort to rubber-band resize. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Wayland Window Management Proposal
On 16 May 2011 16:17, Solerman Kaplon wrote: > Em 13-05-2011 15:38, Michal Suchanek escreveu: >> >> If the client takes, say, half a second to update which is completely >> reasonable for a full re-layout and repaint of a window that normally >> gets only partial updates then the resize will be *very* jerky, and if >> the client is uploading a bitmap over network to update the window you >> can't really avoid that. > > That's why Windows server disable repaint's on windows resize by default > when running over a network. It's just sends the final resize to the window > and you get partial screen updates all the way to it. Users seems to not be > really annoyed by it really. The thing is that in Wayland the server is not aware of any remote vs local windows. Remote applications are in no way part of the protocol and will supposedly sneak in later by means of some remoting proxy. Also there are local sources of lag like applications that are low priority, busy, swapped out, poorly written, etc. This is something that a decent desktop must deal with. > >> You can make the compositor such that the bookkeeping required for >> resizing a window in the compositor does not take long but you have no >> guarantee that every client will do the same, and it's not even >> possible for all clients to achieve. >> >> If you take the client in a debugger example (or otherwise stopped >> client) the window would resize only after the client is started >> again, etc, etc. > > I think current resize in X is good enough. If you are using a debugger, you > ain't any kind of "normal" user who can't understand that if you pause all > threads in the debugger you going to hang screen drawing for that app at the > same time. Well, the whole thread is about the fact that many people here think it is not. On 14 May 2011 01:48, Bill Spitzak wrote: > Michal Suchanek wrote: > >> It may be rubber-band or it may be some other effect but either way >> you need something to draw on the screen until the client performs the >> update which will draw a "not fully updated window" in case the client >> does not update fast enough and by some is "unacceptable in wayland". > > A rubber band resize is part of the window management design and is not a > partial update, any more than the mouse cursor atop a window means it is not > fully updated. The image is fully expected to appear when the user drags the > mouse. > > A rubber band that appears after a timeout when it detects the client is > locked up is what you say, as the user will see an image that they would not > see if the client was responsive. However there is nothing wrong with wrong > images when the compositor detects that the client is not responding. What > is necessary however is that a client that reacts within a timeout will > never display a partially updated image. I guess that this is something that can accommodate both client that repaint in time to have smooth resizes and imperfect clients that require workaround in the compositor for the resizes to appear smooth. As a technical detail since vrefresh is the point when the screen should be updated, it typically happens 50-60times per second and seemingly smooth movement requires about 25fps at the very least the timeout for the compositor to start drawing some replacement should be at most some 2-3 vrefresh intervals. This is something that can be communicated to the client so that it is well aware when it lags. The client, however, must communicate to the wayland window manager the resizability of its window so that the windowmanager can tell apart clients that lag and clients that plain refuse to resize because they rely on the window being fixed size (yuck). If the replacement is the last window content stretched to the new size and slightly blurred then the distortion might not be noticable even for clients that take slightly longer but not too long. For even less cooperative clients the "rubberband" or full window with some generic "stoned" image would be required. There is room for user preferences here for sure. On 14 May 2011 12:09, maledetto wrote: > The only *generally acceptable* way to manage lags in communication I > see is that the server *fades-out* the window in question to signal that > the client is unresponsive and waits for it to respond in a time before > the kill-dialog appears. This is a good standard that doesn't need > hacks or special effects and doesn't paint nonsense on screen. I don't think a client needs to be responsive at all times. It only needs to be responsive at times when a response is required, at other times it can do nothing at all and it's fine. eg. a window resize to be completed properly requires the client to submit a buffer of the new size so that the compositor has some content that it can paint in the new resized window. However, when the compositor decides to hide a window (eg. to switch virtual desktops) the client should be informed but no action is necessarily re
Re: Wayland Window Management Proposal
Em 13-05-2011 15:38, Michal Suchanek escreveu: If the client takes, say, half a second to update which is completely reasonable for a full re-layout and repaint of a window that normally gets only partial updates then the resize will be *very* jerky, and if the client is uploading a bitmap over network to update the window you can't really avoid that. That's why Windows server disable repaint's on windows resize by default when running over a network. It's just sends the final resize to the window and you get partial screen updates all the way to it. Users seems to not be really annoyed by it really. You can make the compositor such that the bookkeeping required for resizing a window in the compositor does not take long but you have no guarantee that every client will do the same, and it's not even possible for all clients to achieve. If you take the client in a debugger example (or otherwise stopped client) the window would resize only after the client is started again, etc, etc. I think current resize in X is good enough. If you are using a debugger, you ain't any kind of "normal" user who can't understand that if you pause all threads in the debugger you going to hang screen drawing for that app at the same time. Solerman ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Wayland Window Management Proposal
The only *generally acceptable* way to manage lags in communication I see is that the server *fades-out* the window in question to signal that the client is unresponsive and waits for it to respond in a time before the kill-dialog appears. This is a good standard that doesn't need hacks or special effects and doesn't paint nonsense on screen. On the other hand, some apps always lag behind and probably should be allowed to do so if they are very important to the user. The question is how. Possibly this could be *configured* via a special effect-plugin that manages single or all windows different to the default setting. This is like *theme'ing* those problematic issues ;) At least it allows the server to follow a strict default mode without forbidding the user to decide differently... regards, maledetto ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Wayland Window Management Proposal
Michal Suchanek wrote: It may be rubber-band or it may be some other effect but either way you need something to draw on the screen until the client performs the update which will draw a "not fully updated window" in case the client does not update fast enough and by some is "unacceptable in wayland". A rubber band resize is part of the window management design and is not a partial update, any more than the mouse cursor atop a window means it is not fully updated. The image is fully expected to appear when the user drags the mouse. A rubber band that appears after a timeout when it detects the client is locked up is what you say, as the user will see an image that they would not see if the client was responsive. However there is nothing wrong with wrong images when the compositor detects that the client is not responding. What is necessary however is that a client that reacts within a timeout will never display a partially updated image. Also note that this requires agreement between Wayland and the application whether the window is resizable to a particular size. Otherwise you might end up with a rubber band displayed forever and both Wayland and the client thinking everything is OK. The client has to acknoledge the event, even if the size (when rounded to what it allows) is the same as it's current size and it therefore does not have to do anything else. The compositor can remove the rubber band image when it sees the acknoledgement. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Wayland Window Management Proposal
On 13 May 2011 22:14, Elijah Insua wrote: > > On May 13, 2011, at 4:02 PM, Casey Dahlin wrote: > >> On Fri, May 13, 2011 at 03:13:01PM +0200, Michal Suchanek wrote: >>> On 13 May 2011 11:26, Daniel Stone wrote: On Thu, May 12, 2011 at 06:22:01PM +0200, Michal Suchanek wrote: > You can't expect that every single client is high-priority and lag-free. Run better clients, then? Or stop trying to micro-optimise for the case of pressing the close button on an unresponsive client? >>> >>> This is not about pressing the close button. It need not have an >>> immediate response and people can accept that, there are workarounds >>> and you close windows only so often. >>> >>> However, window resizes need to be responsive otherwise you introduce >>> lag, possibly to the point that the person moving the mouse has no >>> clue what is going on the moment a window resize is initiated. >>> >> >> You can always use the "rubber band" style of resize, in which case the >> window >> only needs to be told about the resize, and respond to it, when the user >> picks >> a size and drops the corner. >> >> In fact you can pretty easily do both, where the rubber band appears when the >> window hasn't managed to keep up, so the user still has a visual cue to what >> they are doing. >> >> --CJD > > Agreed, although I've always hated the "rubber band" technique as it makes > windows feel fragile. In the slow/unresponsive application case, they > probably are fragile. > It may be rubber-band or it may be some other effect but either way you need something to draw on the screen until the client performs the update which will draw a "not fully updated window" in case the client does not update fast enough and by some is "unacceptable in wayland". Also note that this requires agreement between Wayland and the application whether the window is resizable to a particular size. Otherwise you might end up with a rubber band displayed forever and both Wayland and the client thinking everything is OK. Thanks Michal ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Wayland Window Management Proposal
On May 13, 2011, at 4:02 PM, Casey Dahlin wrote: > On Fri, May 13, 2011 at 03:13:01PM +0200, Michal Suchanek wrote: >> On 13 May 2011 11:26, Daniel Stone wrote: >>> On Thu, May 12, 2011 at 06:22:01PM +0200, Michal Suchanek wrote: You can't expect that every single client is high-priority and lag-free. >>> >>> Run better clients, then? Or stop trying to micro-optimise for the case >>> of pressing the close button on an unresponsive client? >>> >> >> This is not about pressing the close button. It need not have an >> immediate response and people can accept that, there are workarounds >> and you close windows only so often. >> >> However, window resizes need to be responsive otherwise you introduce >> lag, possibly to the point that the person moving the mouse has no >> clue what is going on the moment a window resize is initiated. >> > > You can always use the "rubber band" style of resize, in which case the window > only needs to be told about the resize, and respond to it, when the user picks > a size and drops the corner. > > In fact you can pretty easily do both, where the rubber band appears when the > window hasn't managed to keep up, so the user still has a visual cue to what > they are doing. > > --CJD Agreed, although I've always hated the "rubber band" technique as it makes windows feel fragile. In the slow/unresponsive application case, they probably are fragile. -- Elijah ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Wayland Window Management Proposal
On Fri, May 13, 2011 at 03:13:01PM +0200, Michal Suchanek wrote: > On 13 May 2011 11:26, Daniel Stone wrote: > > On Thu, May 12, 2011 at 06:22:01PM +0200, Michal Suchanek wrote: > >> You can't expect that every single client is high-priority and lag-free. > > > > Run better clients, then? Or stop trying to micro-optimise for the case > > of pressing the close button on an unresponsive client? > > > > This is not about pressing the close button. It need not have an > immediate response and people can accept that, there are workarounds > and you close windows only so often. > > However, window resizes need to be responsive otherwise you introduce > lag, possibly to the point that the person moving the mouse has no > clue what is going on the moment a window resize is initiated. > You can always use the "rubber band" style of resize, in which case the window only needs to be told about the resize, and respond to it, when the user picks a size and drops the corner. In fact you can pretty easily do both, where the rubber band appears when the window hasn't managed to keep up, so the user still has a visual cue to what they are doing. --CJD ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Wayland Window Management Proposal
On Fri, May 13, 2011 at 08:44:23PM +0200, Michal Suchanek wrote: > Again, do you really know only one transition between two frames - flashing? > > With all the effects compositors are capable of today this is the only > thing you can think of? > Fade to corruption? That just means crap is onscreen for a longer amount of time. --CJD ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Wayland Window Management Proposal
Alright - who can think of a good enough excuse for a real-world application to not use a separate GUI/event thread? Even in a pathologically latency-ridden environment, I'm quite certain that in 1 second the event-handling thread could get a timeslice to respond that it's alive. Mak 2011/5/13 Rui Tiago Cação Matos : > On 13 May 2011 18:59, Mike Paquette wrote: >> I hope you guys don't mind my chiming in here. > > Speaking only for myself as mostly a lurker on this list, I very much > welcome your insightful and experienced remarks. Thanks for sharing! > >> The way I handled a window resize was to grow or shrink the window buffer >> and onscreen region as requested by the client, mark it as invalid, and >> hold off on compositing it until the app indicated the buffer was valid, or >> had good content again. A timer in the server acted as a backup for this, >> to allow display update treating the window as containing only the >> background or autofill color for compositing purposes, so things like >> running an app under the debugger wouldn't render the display unusable. The >> compositor treated an 'invalid' buffer as being a 1x1 pixel buffer holding >> the background/autofill color, scaled up to the onscreen window size. >> >> The window resize request could specify that content was to be preserved >> relative to the window origin with new content areas autofilled with the >> background color, or the buffer would just be filled with the autofill >> color, or that the buffer would be left as-is because the app would >> completely repaint the content (as-is could look pretty bad if not >> repainted, what with the wrong rowbyte values and all...). >> >> It did take a bit of work to convince a few app developers that when they >> resized a window, they should immediately fix up the content without >> wandering off to query the odd remote database, but the majority of apps >> appeared to be ready to redraw content promptly on doing a resize. > > Completely agree. The compositor/WM has no business in working around > application bugs. If application programmers are lazy and can't get > their windows acting timely on input then, the ecosystem (users, > distributors) will just "naturally select" those apps out and the well > behaved ones will just be more popular. > > Hiding badly designed applications' problems is just rewarding bad > work and, in this case, it's even worse. If the compositor acts on > input before the application draws the final frame it will create > graphical "flashes" (background color, autofill, junk, whatever) for > *every* application which actually penalizes the good ones because the > graphical glitch will be there, even if for a single frame, since this > is inherently how server side asynchronous actions behave. > > Rui > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Wayland Window Management Proposal
2011/5/13 Rui Tiago Cação Matos : > On 13 May 2011 18:59, Mike Paquette wrote: > Completely agree. The compositor/WM has no business in working around > application bugs. If application programmers are lazy and can't get > their windows acting timely on input then, the ecosystem (users, > distributors) will just "naturally select" those apps out and the well > behaved ones will just be more popular. > > Hiding badly designed applications' problems is just rewarding bad > work and, in this case, it's even worse. If the compositor acts on > input before the application draws the final frame it will create > graphical "flashes" (background color, autofill, junk, whatever) for > *every* application which actually penalizes the good ones because the > graphical glitch will be there, even if for a single frame, since this > is inherently how server side asynchronous actions behave. Again, do you really know only one transition between two frames - flashing? With all the effects compositors are capable of today this is the only thing you can think of? Thanks Michal ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Wayland Window Management Proposal
On 13 May 2011 19:45, Corbin Simpson wrote: > I was trying to stay out of this, but... > > On Fri, May 13, 2011 at 9:03 AM, Michal Suchanek wrote: >> This is *not* *about* *optimization*. If you rely on *every* *single* >> *client* to be responsive for your WM to work then the moment *any* >> *single* *client* becomes unresponsive your WM *breaks*. >> >> If you think a non-broken WM is an optimization I guess we live in >> somewhat different worlds. > > Strawman; it is always possible to multiplex I/O in a way that > prevents any single client from blocking things being done in other > clients or internal server work. > No, you can't if you bind the visible reaction to the input to some operation potentially unbound in time - client update. The user cannot figure out that the window is "virtually" resized and the WM is waiting for client update if the on-screen window is still the same size. If the client takes, say, half a second to update which is completely reasonable for a full re-layout and repaint of a window that normally gets only partial updates then the resize will be *very* jerky, and if the client is uploading a bitmap over network to update the window you can't really avoid that. You can make the compositor such that the bookkeeping required for resizing a window in the compositor does not take long but you have no guarantee that every client will do the same, and it's not even possible for all clients to achieve. If you take the client in a debugger example (or otherwise stopped client) the window would resize only after the client is started again, etc, etc. Oh, and BTW we would not really need this debate if there was a provision for replacing the compositor or window manager or whatever but some time earlier it was suggested that it should be built into the Wayland server and be so awesome that nobody will ever need to replace it with a different one. Thanks Michal ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Wayland Window Management Proposal
On 13 May 2011 18:59, Mike Paquette wrote: > I hope you guys don't mind my chiming in here. Speaking only for myself as mostly a lurker on this list, I very much welcome your insightful and experienced remarks. Thanks for sharing! > The way I handled a window resize was to grow or shrink the window buffer and > onscreen region as requested by the client, mark it as invalid, and hold off > on compositing it until the app indicated the buffer was valid, or had good > content again. A timer in the server acted as a backup for this, to allow > display update treating the window as containing only the background or > autofill color for compositing purposes, so things like running an app under > the debugger wouldn't render the display unusable. The compositor treated an > 'invalid' buffer as being a 1x1 pixel buffer holding the background/autofill > color, scaled up to the onscreen window size. > > The window resize request could specify that content was to be preserved > relative to the window origin with new content areas autofilled with the > background color, or the buffer would just be filled with the autofill color, > or that the buffer would be left as-is because the app would completely > repaint the content (as-is could look pretty bad if not repainted, what with > the wrong rowbyte values and all...). > > It did take a bit of work to convince a few app developers that when they > resized a window, they should immediately fix up the content without > wandering off to query the odd remote database, but the majority of apps > appeared to be ready to redraw content promptly on doing a resize. Completely agree. The compositor/WM has no business in working around application bugs. If application programmers are lazy and can't get their windows acting timely on input then, the ecosystem (users, distributors) will just "naturally select" those apps out and the well behaved ones will just be more popular. Hiding badly designed applications' problems is just rewarding bad work and, in this case, it's even worse. If the compositor acts on input before the application draws the final frame it will create graphical "flashes" (background color, autofill, junk, whatever) for *every* application which actually penalizes the good ones because the graphical glitch will be there, even if for a single frame, since this is inherently how server side asynchronous actions behave. Rui ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Wayland Window Management Proposal
I hope you guys don't mind my chiming in here. The way I handled a window resize was to grow or shrink the window buffer and onscreen region as requested by the client, mark it as invalid, and hold off on compositing it until the app indicated the buffer was valid, or had good content again. A timer in the server acted as a backup for this, to allow display update treating the window as containing only the background or autofill color for compositing purposes, so things like running an app under the debugger wouldn't render the display unusable. The compositor treated an 'invalid' buffer as being a 1x1 pixel buffer holding the background/autofill color, scaled up to the onscreen window size. The window resize request could specify that content was to be preserved relative to the window origin with new content areas autofilled with the background color, or the buffer would just be filled with the autofill color, or that the buffer would be left as-is because the app would completely repaint the content (as-is could look pretty bad if not repainted, what with the wrong rowbyte values and all...). It did take a bit of work to convince a few app developers that when they resized a window, they should immediately fix up the content without wandering off to query the odd remote database, but the majority of apps appeared to be ready to redraw content promptly on doing a resize. Mike Paquette On May 13, 2011, at 10:37 AM, Bill Spitzak wrote: > > > Michal Suchanek wrote: > >>> Yes: it handles all resizing uniformly badly. It's pretty horrible. >> So you can see the background color of clients that are slow to >> repaint. Oh, how painful. > > Yes, that is UNACCEPTABLE! Get it through your head that the intention of > Wayland is so that Linux stops looking like crap compared to other systems. > NEVER NEVER NEVER should a "partially updated window" appear. If it does, > Wayland is junk. This means your idea violates one of the basic design > principles of Wayland and cannot be done. > > You also have to face it that programs lock up and don't respond to all kinds > of actions and it is silly to try to address just resize. If the window is > not going to draw I would prefer it not to resize so I don't lose the old > contents. > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Wayland Window Management Proposal
I was trying to stay out of this, but... On Fri, May 13, 2011 at 9:03 AM, Michal Suchanek wrote: > This is *not* *about* *optimization*. If you rely on *every* *single* > *client* to be responsive for your WM to work then the moment *any* > *single* *client* becomes unresponsive your WM *breaks*. > > If you think a non-broken WM is an optimization I guess we live in > somewhat different worlds. Strawman; it is always possible to multiplex I/O in a way that prevents any single client from blocking things being done in other clients or internal server work. ~ C. P.S. I want an amethyst bikeshed. Not purple, mind you; I want the bikeshed carved out of a giant amethyst geode. It'll be awesome, I promise. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Wayland Window Management Proposal
This will pretty quickly result in toolkits, or at least app skeletons, doing something like: (void)max_unresponsive_time(MAX_DOUBLE); I had an 'automatic wait cursor' feature in a window system I did, which when an app failed to process pending events for a few seconds, would automatically display a 'wait cursor', the dreaded Spinning Pizza of Death. Naturally, app developers were insulted that the system would dare indicate that their app was being unresponsive, and demanded such an API. Being the annoying curmudgeon that I am, I refused to allow apps to feign being responsive when they really weren't, as that wound up annoying users even more. (System cues shouldn't lie to users.) I did use the same mechanism to post notifications to subscribing apps when an application became unresponsive. This allows an app that shows the status of other apps, like the Unity launch bar, to listen for notifications of unresponsive apps, specially badge unresponsive apps if desired, or offer a 'force quit' contextual menu item. Mike Paquette On May 13, 2011, at 4:11 AM, Mak Nazečić-Andrlon wrote: > Indeed. But how about this: the client sends the compositor a hint > stating its maximum unresponsiveness interval, and sends keep-alive > messages when idle. If the app doesn't respond in time, and the user > tries to interact with it, the compositor can offer to kill it (or > something). > > Mak > > On Fri, May 13, 2011 at 11:26 AM, Daniel Stone wrote: >> On Thu, May 12, 2011 at 06:22:01PM +0200, Michal Suchanek wrote: >>> You can't expect that every single client is high-priority and lag-free. >> >> Run better clients, then? Or stop trying to micro-optimise for the case >> of pressing the close button on an unresponsive client? >> >> Cheers, >> Daniel, who wants the bikeshed to be violet >> ___ >> wayland-devel mailing list >> wayland-devel@lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/wayland-devel >> > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Wayland Window Management Proposal
Michal Suchanek wrote: Yes: it handles all resizing uniformly badly. It's pretty horrible. So you can see the background color of clients that are slow to repaint. Oh, how painful. Yes, that is UNACCEPTABLE! Get it through your head that the intention of Wayland is so that Linux stops looking like crap compared to other systems. NEVER NEVER NEVER should a "partially updated window" appear. If it does, Wayland is junk. This means your idea violates one of the basic design principles of Wayland and cannot be done. You also have to face it that programs lock up and don't respond to all kinds of actions and it is silly to try to address just resize. If the window is not going to draw I would prefer it not to resize so I don't lose the old contents. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Wayland Window Management Proposal
On 13 May 2011 17:25, Daniel Stone wrote: > Hi, > > On Fri, May 13, 2011 at 03:13:01PM +0200, Michal Suchanek wrote: >> However, window resizes need to be responsive otherwise you introduce >> lag, possibly to the point that the person moving the mouse has no >> clue what is going on the moment a window resize is initiated. > > Sure. > >> Lag is something that can easily kill otherwise workable interface, >> and fractions of second might seem reasonable on the drawing board but >> they are still lag. >> >> Lag-free resize is not something reasonably doable if you have to wait >> for the client to respond for every size change to take place. > > Clients need to participate in the resize. Else what are you going to > draw? Magically infer window contents? Fill the newly-exposed areas with > background colour? I don't really care. Responsive clients will repaint and you will not notice anything amiss, for unresponsive clients anything is better than leaving you wondering what is going on because you dragged this window border and it is stuck. > >> X can handle remote clients and low priority clients participating in >> the desktop environment. > > Yes: it handles all resizing uniformly badly. It's pretty horrible. So you can see the background color of clients that are slow to repaint. Oh, how painful. However, the fact that you *can* see the background means that if you were waiting for the client to repaint before changing the window size your experience resizing the window would be *horrible*. OK, I guess you can wait some 2-3 vrefresh intervals for the client to repaint and only then start ignoring it. > >> And this is not skipping a micro-optimization, this is closing the >> desktop for entry of whole classes of clients. > > Clients which cannot be relied upon to respond promptly to anything you > ask them to do? I don't think they're a target for premature > optimisation, to be quite honest. > This is *not* *about* *optimization*. If you rely on *every* *single* *client* to be responsive for your WM to work then the moment *any* *single* *client* becomes unresponsive your WM *breaks*. If you think a non-broken WM is an optimization I guess we live in somewhat different worlds. Thanks Michal ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Wayland Window Management Proposal
Hi, On Fri, May 13, 2011 at 03:13:01PM +0200, Michal Suchanek wrote: > However, window resizes need to be responsive otherwise you introduce > lag, possibly to the point that the person moving the mouse has no > clue what is going on the moment a window resize is initiated. Sure. > Lag is something that can easily kill otherwise workable interface, > and fractions of second might seem reasonable on the drawing board but > they are still lag. > > Lag-free resize is not something reasonably doable if you have to wait > for the client to respond for every size change to take place. Clients need to participate in the resize. Else what are you going to draw? Magically infer window contents? Fill the newly-exposed areas with background colour? > X can handle remote clients and low priority clients participating in > the desktop environment. Yes: it handles all resizing uniformly badly. It's pretty horrible. > And this is not skipping a micro-optimization, this is closing the > desktop for entry of whole classes of clients. Clients which cannot be relied upon to respond promptly to anything you ask them to do? I don't think they're a target for premature optimisation, to be quite honest. Cheers, Daniel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Wayland Window Management Proposal
On 13 May 2011 11:26, Daniel Stone wrote: > On Thu, May 12, 2011 at 06:22:01PM +0200, Michal Suchanek wrote: >> You can't expect that every single client is high-priority and lag-free. > > Run better clients, then? Or stop trying to micro-optimise for the case > of pressing the close button on an unresponsive client? > This is not about pressing the close button. It need not have an immediate response and people can accept that, there are workarounds and you close windows only so often. However, window resizes need to be responsive otherwise you introduce lag, possibly to the point that the person moving the mouse has no clue what is going on the moment a window resize is initiated. Lag is something that can easily kill otherwise workable interface, and fractions of second might seem reasonable on the drawing board but they are still lag. Lag-free resize is not something reasonably doable if you have to wait for the client to respond for every size change to take place. X can handle remote clients and low priority clients participating in the desktop environment. If Wayland can't then it is not an evolution of X, it is a step backward. And this is not skipping a micro-optimization, this is closing the desktop for entry of whole classes of clients. Thanks Michal ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Wayland Window Management Proposal
Indeed. But how about this: the client sends the compositor a hint stating its maximum unresponsiveness interval, and sends keep-alive messages when idle. If the app doesn't respond in time, and the user tries to interact with it, the compositor can offer to kill it (or something). Mak On Fri, May 13, 2011 at 11:26 AM, Daniel Stone wrote: > On Thu, May 12, 2011 at 06:22:01PM +0200, Michal Suchanek wrote: >> You can't expect that every single client is high-priority and lag-free. > > Run better clients, then? Or stop trying to micro-optimise for the case > of pressing the close button on an unresponsive client? > > Cheers, > Daniel, who wants the bikeshed to be violet > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Wayland Window Management Proposal
On Thu, May 12, 2011 at 06:22:01PM +0200, Michal Suchanek wrote: > You can't expect that every single client is high-priority and lag-free. Run better clients, then? Or stop trying to micro-optimise for the case of pressing the close button on an unresponsive client? Cheers, Daniel, who wants the bikeshed to be violet ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Wayland Window Management Proposal
On 11 May 2011 20:25, Bill Spitzak wrote: > Michal Suchanek wrote: > >> Moves and resizes implemented in the client can't work well. > > Any resize solution that does not allow an atomic on-screen update of a > window to it's new size, with the resized decorations and contents, is > unacceptable. The whole point of Wayland is that the user NEVER sees a > partially-updated window. > > It is therefore impossible to finish a resize without waiting for the client > to update the window contents. Since you have to wait for that, there is no > reason the client can't also draw the decorations. I'm sorry if this makes > writing clients harder. Deal with it. Always waiting for the client is something that cannot be upheld. There are situations when - the client is busy or stuck - the client is swapped out or a low priority process - the client is remote and therefore resizing it will take some time whatever you do If Wayland can't deal with any of the above it's junk. The window management functions should be working without lag so long as the window manager and Wayland server have enough resources and high enough priority. You can't expect that every single client is high-priority and lag-free. Thanks Michal ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Wayland Window Management Proposal
On 11 May 2011 20:25, Bill Spitzak wrote: > Michal Suchanek wrote: > >> Moves and resizes implemented in the client can't work well. > > Any resize solution that does not allow an atomic on-screen update of a > window to it's new size, with the resized decorations and contents, is > unacceptable. The whole point of Wayland is that the user NEVER sees a > partially-updated window. > > It is therefore impossible to finish a resize without waiting for the client > to update the window contents. Since you have to wait for that, there is no > reason the client can't also draw the decorations. I'm sorry if this makes > writing clients harder. Deal with it. Then rewrite all the applications. When you are done with that we can get rid of server side resizes. > >> So the user initiated resizes should happen in the compositor which >> paints the current content in the window of the new size and can >> possibly mix in some haze to make it obvious that the window was not >> resized yet and later the application should update the content size >> to match the window size and move any toolbars appropriately. > > That would look like crap. The window would blink rapidly between the "haze" > and final version. Oh, come on, can't you came up with some real excuse? With all the various effects the compositors implement have you never heard of fade-in? Thanks Michal ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Wayland Window Management Proposal
Michal Suchanek wrote: Moves and resizes implemented in the client can't work well. Any resize solution that does not allow an atomic on-screen update of a window to it's new size, with the resized decorations and contents, is unacceptable. The whole point of Wayland is that the user NEVER sees a partially-updated window. It is therefore impossible to finish a resize without waiting for the client to update the window contents. Since you have to wait for that, there is no reason the client can't also draw the decorations. I'm sorry if this makes writing clients harder. Deal with it. So the user initiated resizes should happen in the compositor which paints the current content in the window of the new size and can possibly mix in some haze to make it obvious that the window was not resized yet and later the application should update the content size to match the window size and move any toolbars appropriately. That would look like crap. The window would blink rapidly between the "haze" and final version. The problem is with broken applications (such as gimp) that respond to a resize of their window with application-initiated resize of the same window leading to a resize loop in tiling WMs. That is a problem with X design where they tried to override the actual call to resize the window. In wayland the "change the window size" and the "I want to change the window size" messages are distinct. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Wayland Window Management Proposal
cat wrote: If I understand the proposal correctly this shouldn't be a problem. If the application becomes unresponsive the server has the ability to manage it (move, resize, raise, lower, possibly hide/show, and an option to kill it) and it knows if it didn't respond to events. I do think that there is one thing it should also have, when a client is going to appear/move/resize, it should send a request to the server with a tag, a nospace string to identify the request, the new location, and new dimentions. the server responds with a message that has the same tag, and a yes or no response (possibly a hint as to why it was rejected), and if the resonce is no then the client should not preform that particular operation. this at its basics can prevent applications from accidentally moving off screen, covering some more important window(like a taskbar), or from acting as a floating window in a tiling environment, and allows the server the freedom to do something more advanced. You may be right. Instead of what I proposed where a client sends messages indicating it *did* something, it can instead send messages that indicate it *wants* to do something. All actions would happen after the compositor sends messages to the client, and they would all still be performed by the client so they can be atomic. If a client on it's own decided it wanted to resize, this is what should happen: 1. It would send a resize-request message to the compositor. 2. The compositor would adjust the size to what it requires. It would then send the adjusted resize-request back to the client 3. The client could then further adjust the resize-request but it should not move sides of the window where the 'edge' flag is set. This allows it to obey any internal rules about a grid or aspect ratio. It then resizes the window and draws the resized contents and decorations. Any resizes generated by the compositor (either due to the client telling the compositor to do resize/drag tracking, or due to a popup menu or Alt+click override or tiling adjustments) would cause the compositor to send a resize-request to the client, identical to step 2 above. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Wayland Window Management Proposal
If I understand the proposal correctly this shouldn't be a problem. If the application becomes unresponsive the server has the ability to manage it (move, resize, raise, lower, possibly hide/show, and an option to kill it) and it knows if it didn't respond to events. I do think that there is one thing it should also have, when a client is going to appear/move/resize, it should send a request to the server with a tag, a nospace string to identify the request, the new location, and new dimentions. the server responds with a message that has the same tag, and a yes or no response (possibly a hint as to why it was rejected), and if the resonce is no then the client should not preform that particular operation. this at its basics can prevent applications from accidentally moving off screen, covering some more important window(like a taskbar), or from acting as a floating window in a tiling environment, and allows the server the freedom to do something more advanced. On Wed, May 11, 2011 at 5:02 AM, Michal Suchanek wrote: > 2011/5/11 Bill Spitzak : > > Kristian Høgsberg wrote: > > > >> I had a quick read through this and there is a lot of overlap with how > >> Wayland works today... are you proposing to change how Wayland works > >> or are you not familiar with what's already in place? > > > > A lot of this is based on my understanding of how Wayland works, and from > > the XML description of the protocol. I tried to document what I believe > but > > has never been really stated for Wayland. > > > > Main addition I made without previous knowledge was the parent and the > task > > objects (so that a task manager client can figure out what to display), > and > > the window management events (rather than try to guess what happens based > on > > movements of the windows, which seemed to be what was planned for > Wayland). > > > >> Anyway, for decorations and tiling window managers, bear in mind that > >> CSD is not about insisting that clients always draws decorations, but > >> about making clients draw the decorations *when* decorations are > >> desired. > > > > I mostly see CSD as meaning "the server never draws any kind of > > decorations". I agree it is a good idea for the server to be able to tell > > the client to not to draw decorations (done in this proposal with the > resize > > events having 4 flags to turn the edges on/off and another flag for the > > title bar). But the server must *never* draw them, because that would > > require the api by which the client describes the decorations to the > server, > > which is the source of the complexity and interface lock-in that we have > in > > X and Windows. > > I don't think you need an API for that. Either the application accepts > what the server draws or it wants to draw its own. > So it's like > - application wants its own borders (bool) > - server takes care of borders (bool) > two bits. > > > > > I also believe window actions such as move, map, and raise must be > > client-side. Otherwise correct movement of child windows will require an > > equally-complex api to send this information to the server. So I really > > tried to make it clear how I see this working. Proper child windows where > > the app has complete control could be a major user interface advantage > over > > Windows and OS/X. > > Moves and resizes implemented in the client can't work well. > > Maybe in an ideal world each application would be split into two (or > more) processes, one taking care of the UI interaction and the > other(s) doing the actual work so that the UI is always responsive. > > However, this is not the case and for moves and resizes to work > properly they have to be done in the window manager. For many > applications responding to UI events is rather low priority and when > they are busy doing something the UI is not going to be handled. > > So the user initiated resizes should happen in the compositor which > paints the current content in the window of the new size and can > possibly mix in some haze to make it obvious that the window was not > resized yet and later the application should update the content size > to match the window size and move any toolbars appropriately. > > The problem is with broken applications (such as gimp) that respond to > a resize of their window with application-initiated resize of the same > window leading to a resize loop in tiling WMs. > > Thanks > > Michal > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Wayland Window Management Proposal
On 11 May 2011 14:31, Mark Constable wrote: > On 2011-05-11, Michal Suchanek wrote: >> Maybe in an ideal world each application would be split >> into two (or more) processes, one taking care of the UI >> interaction and the other(s) doing the actual work so >> that the UI is always responsive. >> >> However, this is not the case and for moves and resizes >> to work properly they have to be done in the window >> manager. For many applications responding to UI events >> is rather low priority and when they are busy doing >> something the UI is not going to be handled. > > Perhaps a compromise could be a wayland-client.so lib that > all compliant Wayland applications must link to at runtime > and it provides consistant window management functionality. For that to work the library would have to create an UI thread which is always ready to respond to resize requests, and it could *not* do the actual drawing which can be potentially time consuming. I don't see what you get here. Many applications will refuse to use that because they cannot accept multi-threaded operation for some technical reason (usually imposed by some other library) and you still don't get any guarantee about the behaviour because the moment this library invokes any application supplied callback it does not guarantee anything and when it does not it cannot do anything being virtually useless. Plus even if you provided such lib and it somehow worked it would be useless for applications written in sane languages (eg. not C). Thanks Michal ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Wayland Window Management Proposal
On 2011-05-11, Michal Suchanek wrote: > Maybe in an ideal world each application would be split > into two (or more) processes, one taking care of the UI > interaction and the other(s) doing the actual work so > that the UI is always responsive. > > However, this is not the case and for moves and resizes > to work properly they have to be done in the window > manager. For many applications responding to UI events > is rather low priority and when they are busy doing > something the UI is not going to be handled. Perhaps a compromise could be a wayland-client.so lib that all compliant Wayland applications must link to at runtime and it provides consistant window management functionality. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Wayland Window Management Proposal
2011/5/11 Bill Spitzak : > Kristian Høgsberg wrote: > >> I had a quick read through this and there is a lot of overlap with how >> Wayland works today... are you proposing to change how Wayland works >> or are you not familiar with what's already in place? > > A lot of this is based on my understanding of how Wayland works, and from > the XML description of the protocol. I tried to document what I believe but > has never been really stated for Wayland. > > Main addition I made without previous knowledge was the parent and the task > objects (so that a task manager client can figure out what to display), and > the window management events (rather than try to guess what happens based on > movements of the windows, which seemed to be what was planned for Wayland). > >> Anyway, for decorations and tiling window managers, bear in mind that >> CSD is not about insisting that clients always draws decorations, but >> about making clients draw the decorations *when* decorations are >> desired. > > I mostly see CSD as meaning "the server never draws any kind of > decorations". I agree it is a good idea for the server to be able to tell > the client to not to draw decorations (done in this proposal with the resize > events having 4 flags to turn the edges on/off and another flag for the > title bar). But the server must *never* draw them, because that would > require the api by which the client describes the decorations to the server, > which is the source of the complexity and interface lock-in that we have in > X and Windows. I don't think you need an API for that. Either the application accepts what the server draws or it wants to draw its own. So it's like - application wants its own borders (bool) - server takes care of borders (bool) two bits. > > I also believe window actions such as move, map, and raise must be > client-side. Otherwise correct movement of child windows will require an > equally-complex api to send this information to the server. So I really > tried to make it clear how I see this working. Proper child windows where > the app has complete control could be a major user interface advantage over > Windows and OS/X. Moves and resizes implemented in the client can't work well. Maybe in an ideal world each application would be split into two (or more) processes, one taking care of the UI interaction and the other(s) doing the actual work so that the UI is always responsive. However, this is not the case and for moves and resizes to work properly they have to be done in the window manager. For many applications responding to UI events is rather low priority and when they are busy doing something the UI is not going to be handled. So the user initiated resizes should happen in the compositor which paints the current content in the window of the new size and can possibly mix in some haze to make it obvious that the window was not resized yet and later the application should update the content size to match the window size and move any toolbars appropriately. The problem is with broken applications (such as gimp) that respond to a resize of their window with application-initiated resize of the same window leading to a resize loop in tiling WMs. Thanks Michal ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Wayland Window Management Proposal
Kristian Høgsberg wrote: I had a quick read through this and there is a lot of overlap with how Wayland works today... are you proposing to change how Wayland works or are you not familiar with what's already in place? A lot of this is based on my understanding of how Wayland works, and from the XML description of the protocol. I tried to document what I believe but has never been really stated for Wayland. Main addition I made without previous knowledge was the parent and the task objects (so that a task manager client can figure out what to display), and the window management events (rather than try to guess what happens based on movements of the windows, which seemed to be what was planned for Wayland). Anyway, for decorations and tiling window managers, bear in mind that CSD is not about insisting that clients always draws decorations, but about making clients draw the decorations *when* decorations are desired. I mostly see CSD as meaning "the server never draws any kind of decorations". I agree it is a good idea for the server to be able to tell the client to not to draw decorations (done in this proposal with the resize events having 4 flags to turn the edges on/off and another flag for the title bar). But the server must *never* draw them, because that would require the api by which the client describes the decorations to the server, which is the source of the complexity and interface lock-in that we have in X and Windows. I also believe window actions such as move, map, and raise must be client-side. Otherwise correct movement of child windows will require an equally-complex api to send this information to the server. So I really tried to make it clear how I see this working. Proper child windows where the app has complete control could be a major user interface advantage over Windows and OS/X. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Wayland Window Management Proposal
On Tue, May 10, 2011 at 8:35 PM, Bill Spitzak wrote: > With all the discussion about client side decorations, I thought I would try > to write how window management could actually be done in Wayland. This is a > really serious attempt to get the simplest system I could come up with, > while still allowing for some of the legitimate gripes, in particular to > make it not be impossible to do tiled window management. I had a quick read through this and there is a lot of overlap with how Wayland works today... are you proposing to change how Wayland works or are you not familiar with what's already in place? Anyway, for decorations and tiling window managers, bear in mind that CSD is not about insisting that clients always draws decorations, but about making clients draw the decorations *when* decorations are desired. Kristian > This I hope is in enough detail that it that it is not ambiguous whether > this design does something or fails to do it. Too much of the client side > decoration argument is making false assumptions about what the system will > do. > > = Wayland Window Management proposal = > > == Object Parent == > > All Wayland objects have a single "parent", which is another object or > NULL. When an object is first created it's parent is NULL, but it can > be set to any other object afterwards. If the attempt to set the > parent produces a loop that is an error and the parent is > unchanged. If a parent is deleted the child's parent is set to > NULL. All parent changes produce events. > > The purpose is to build hierarchies that task managers need in order > to display everything in a useful way to users. This has no effect on > the display or how windows act. > > == Object Name == > > All objects have a single UTF-8 string attached to them that is the > "name". The purpose of the name is to provide something to show the > user when a program can't or does not want to display an image. > > == Task objects == > > Task objects are windows but their purpose is to appear in a "task > list". They probably don't have an actual image allocated. > > There is a global task created by the compositor, tasks that should be > visible are attached to this as children. Below that can be a > hierarchy of more tasks and then actual windows (i'm not sure if there > will need to be a way to distinguish tasks from windows). > > The image that appears in the task list may be the surface attached to > the task object, or maybe some children with specific names. Not sure > exactly how to do this but it would be nice if clients could control > this to draw indicators, etc. Compositors can fall back to showing the > name if no other image is found. > > == Multiple-surface windows == > > What appears to be a single window to the user may be several Wayland > windows. In particlar a video-playback program may have a YUV surface > resized on screen to zoom the pixels, overlaid with a "frame" window > which is an unscaled RGBA image of all the controls around and > overlaid on the video. It is important that window management support > this and them move and resize in exact lock. > > To indicate this the YUV surface should be a child of the frame > and below the frame. > > == Client side decorations == > > The client is responsible for drawing every single pixel in a window > that the user would click on and expect to go to the client. This > includes the window title and the borders on all sides of the window. > > Non-rectangular windows are done by leaving the portion between the > window and the rectangle transparent black (all zero). > > "shadows" are done by the compositor as the pixels they occupy belong > to the windows the shadows fall on. It can produce shadows for > non-rectangular windows by using the alpha to create the shadow. > > "blurry opacity" is done by the compositor. It must not blur video > playback children and not blur 100% transparent areas or the > antialiased edges of these areas. I don't know how clients can control > the blur, but perhaps color values greater than alpha can indicate > blurring. > > == Compositor Window Management == > > The compositor can produce events that clients are expected to respond > to and update their windows appropriately. The compositor *NEVER* > moves or does anything to the windows, as this would produce > asynchronous updates. The clients must do this so they can immediatly > draw the new contents. > > These events are produced by task manager windows, or by Alt+mouse > style overrides, NOT by the user clicking on the window borders or > contents. Clicks actually in the windows are expected to be h
Wayland Window Management Proposal
With all the discussion about client side decorations, I thought I would try to write how window management could actually be done in Wayland. This is a really serious attempt to get the simplest system I could come up with, while still allowing for some of the legitimate gripes, in particular to make it not be impossible to do tiled window management. This I hope is in enough detail that it that it is not ambiguous whether this design does something or fails to do it. Too much of the client side decoration argument is making false assumptions about what the system will do. = Wayland Window Management proposal = == Object Parent == All Wayland objects have a single "parent", which is another object or NULL. When an object is first created it's parent is NULL, but it can be set to any other object afterwards. If the attempt to set the parent produces a loop that is an error and the parent is unchanged. If a parent is deleted the child's parent is set to NULL. All parent changes produce events. The purpose is to build hierarchies that task managers need in order to display everything in a useful way to users. This has no effect on the display or how windows act. == Object Name == All objects have a single UTF-8 string attached to them that is the "name". The purpose of the name is to provide something to show the user when a program can't or does not want to display an image. == Task objects == Task objects are windows but their purpose is to appear in a "task list". They probably don't have an actual image allocated. There is a global task created by the compositor, tasks that should be visible are attached to this as children. Below that can be a hierarchy of more tasks and then actual windows (i'm not sure if there will need to be a way to distinguish tasks from windows). The image that appears in the task list may be the surface attached to the task object, or maybe some children with specific names. Not sure exactly how to do this but it would be nice if clients could control this to draw indicators, etc. Compositors can fall back to showing the name if no other image is found. == Multiple-surface windows == What appears to be a single window to the user may be several Wayland windows. In particlar a video-playback program may have a YUV surface resized on screen to zoom the pixels, overlaid with a "frame" window which is an unscaled RGBA image of all the controls around and overlaid on the video. It is important that window management support this and them move and resize in exact lock. To indicate this the YUV surface should be a child of the frame and below the frame. == Client side decorations == The client is responsible for drawing every single pixel in a window that the user would click on and expect to go to the client. This includes the window title and the borders on all sides of the window. Non-rectangular windows are done by leaving the portion between the window and the rectangle transparent black (all zero). "shadows" are done by the compositor as the pixels they occupy belong to the windows the shadows fall on. It can produce shadows for non-rectangular windows by using the alpha to create the shadow. "blurry opacity" is done by the compositor. It must not blur video playback children and not blur 100% transparent areas or the antialiased edges of these areas. I don't know how clients can control the blur, but perhaps color values greater than alpha can indicate blurring. == Compositor Window Management == The compositor can produce events that clients are expected to respond to and update their windows appropriately. The compositor *NEVER* moves or does anything to the windows, as this would produce asynchronous updates. The clients must do this so they can immediatly draw the new contents. These events are produced by task manager windows, or by Alt+mouse style overrides, NOT by the user clicking on the window borders or contents. Clicks actually in the windows are expected to be handled by the clients or by the filtering described below. === Close === Sent to a task or window indicating that the user wants it to go away. A typical response is to ask the user if they are sure, to destroy or unmap the window, to destroy or unmap other child windows, and for the client to exit. === Hide === Sent to a task or window indicating that the user wants it off the screen but wants to bring it back later. Typical response is to unmap windows. === Show === Sent to a task or window indicating that the user wants it on the screen. Typical response is to map windows. === Activate === Sent to a task or window, includes a non-pointer input device (usually the keyboard). Indicates that the device's events will be sent to that task or window. Typical response is to change the graphics to show this and to make toolboxes appear. Note that the events may be sent to
