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 16 May 2011 23:13, Bill Spitzak spit...@gmail.com 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
On 16 May 2011 16:17, Solerman Kaplon soler...@gmail.com 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 spit...@gmail.com 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 malede...@online.de 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 required on the client's
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 malede...@online.de ___ 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
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 dan...@fooishbar.org 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 13 May 2011 11:26, Daniel Stone dan...@fooishbar.org 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
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
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
On 13 May 2011 18:59, Mike Paquette paquette...@gmail.com 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
On 13 May 2011 19:45, Corbin Simpson mostawesomed...@gmail.com wrote: I was trying to stay out of this, but... On Fri, May 13, 2011 at 9:03 AM, Michal Suchanek hramr...@centrum.cz 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
2011/5/13 Rui Tiago Cação Matos tiagoma...@gmail.com: On 13 May 2011 18:59, Mike Paquette paquette...@gmail.com 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
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 tiagoma...@gmail.com: On 13 May 2011 18:59, Mike Paquette paquette...@gmail.com 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
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
On Fri, May 13, 2011 at 03:13:01PM +0200, Michal Suchanek wrote: On 13 May 2011 11:26, Daniel Stone dan...@fooishbar.org 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 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 dan...@fooishbar.org 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 13 May 2011 22:14, Elijah Insua tmp...@gmail.com 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 dan...@fooishbar.org 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 11 May 2011 20:25, Bill Spitzak spit...@gmail.com 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 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
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 hramr...@centrum.czwrote: 2011/5/11 Bill Spitzak spit...@gmail.com: 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
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
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
