.
= Wayland Window Management proposal =
== Object Parent ==
All Wayland objects have a single "parent", which is another object or
NULL. When an object is first created it's parent is NULL, but it can
be set to any other object afterwards. If the attempt to set the
parent produces a loop t
that it that it is not ambiguous whether
> this design does something or fails to do it. Too much of the client side
> decoration argument is making false assumptions about what the system will
> do.
>
> = Wayland Window Management proposal =
>
> == Object Parent ==
>
> Al
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
2011/5/11 Bill Spitzak :
> Kristian Høgsberg wrote:
>
>> I had a quick read through this and there is a lot of overlap with how
>> Wayland works today... are you proposing to change how Wayland works
>> or are you not familiar with what's already in place?
>
> A lot of this is based on my understan
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
On 11 May 2011 14:31, Mark Constable wrote:
> On 2011-05-11, Michal Suchanek wrote:
>> Maybe in an ideal world each application would be split
>> into two (or more) processes, one taking care of the UI
>> interaction and the other(s) doing the actual work so
>> that the UI is always responsive.
>>
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 t
cat wrote:
If I understand the proposal correctly this shouldn't be a problem. If
the application becomes unresponsive the server has the ability to
manage it (move, resize, raise, lower, possibly hide/show, and an option
to kill it) and it knows if it didn't respond to events.
I do think t
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 s
On 11 May 2011 20:25, Bill Spitzak wrote:
> Michal Suchanek wrote:
>
>> Moves and resizes implemented in the client can't work well.
>
> Any resize solution that does not allow an atomic on-screen update of a
> window to it's new size, with the resized decorations and contents, is
> unacceptable.
On 11 May 2011 20:25, Bill Spitzak wrote:
> Michal Suchanek wrote:
>
>> Moves and resizes implemented in the client can't work well.
>
> Any resize solution that does not allow an atomic on-screen update of a
> window to it's new size, with the resized decorations and contents, is
> unacceptable.
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
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
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 n
On 16 May 2011 16:17, Solerman Kaplon wrote:
> Em 13-05-2011 15:38, Michal Suchanek escreveu:
>>
>> If the client takes, say, half a second to update which is completely
>> reasonable for a full re-layout and repaint of a window that normally
>> gets only partial updates then the resize will be *v
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
On 16 May 2011 23:13, Bill Spitzak wrote:
> Michal Suchanek wrote:
>
>> The thing is that in Wayland the server is not aware of any remote vs
>> local windows. Remote applications are in no way part of the protocol
>> and will supposedly sneak in later by means of some remoting proxy.
>
> My under
> I think the wayland compositor could track how long the clients take to
> respond to events. They would only disable if they suddenly took several
> times longer than before. If the recorded lag exceeds a threshold the
> compositor could resort to rubber-band resize.
What is a "response to an ev
On 17 May 2011 18:01, Sam Spilsbury wrote:
>> I think the wayland compositor could track how long the clients take to
>> respond to events. They would only disable if they suddenly took several
>> times longer than before. If the recorded lag exceeds a threshold the
>> compositor could resort to r
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 t
El dc 18 de 05 de 2011 a les 11:17 -0700, en/na Bill Spitzak va
escriure:
> Michal Suchanek wrote:
>
> [...] I think there is also a
> problem in that the compositor cannot be absolutely certain that a given
> resize is in response to a resize request.
It doesn't need to, as it makes no differe
On 19/05/11 04:17, Bill Spitzak wrote:
Michal Suchanek wrote:
In the case of a resize event the response includes submitting a
buffer containing resized window content to the compositor.
The compositor requires this new resized content to draw the window so
it cannot be avoided.
I think the
39 matches
Mail list logo
