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
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
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, Ma
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
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 someth
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
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 lo
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 automatic
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*
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.
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 win
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*
>> *s
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,
> distrib
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 Ru
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 onscr
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
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 an
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
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 way
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 __real
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.
21 matches
Mail list logo
