Re: vmwgfx
On Sat, May 14, 2011 at 12:28 AM, Christopher Friedt 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
Re: vmwgfx
Hi Doug, On Thu, Apr 21, 2011 at 3:59 PM, Doug Schaefer wrote: > Is anyone working to get Wayland working with the vmware vmwgfx > driver, or is this just a real bad idea? I'm actually nearing the point of a small-ish project, where having a wayland-friendly vmware graphics stack would be __really__ helpful for development. 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. Have you contacted VMWare yet with your suggestion? I might actually know one person who works there, so I'll see if I can drum up some information. Cheers, C ___ 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: 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
