Re: client side decorations
On Thu, May 12, 2011 at 10:15:31PM +0200, Michal Suchanek wrote: That's not really true. Of course, there are things that look awful in different DPI (or because you happen to have slightly different fonts than the author) because they were done by braindead people. This includes but is not limited to - many web sites - (some?) Adobe and HP software - OS X (which actually prevents changing the DPI in the first place leaving you with ridiculous font sizes) ... so, pretty much everything, then. Can we please move on? Thanks. ___ 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: vmwgfx
On Sat, May 14, 2011 at 12:28 AM, Christopher Friedt chrisfri...@gmail.com wrote: In my opinion, it makes a lot of sense, but I have no idea if any of the vmware graphics drivers are open, which is a bit of a hinderance. I should say, if they're _not_ open, then it's a bit of a hinderance. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
