headers
Deron Johnson | 9 Nov 2004 20:55
Picon

My design status

Here is a status update on my thinking regarding the design of the LG
event system. Around August of this year I was pursuing a design in
which the grabbing was done in the Display Server. In order to achieve
this, topology changes to the window tree would be sent from the X
server to the LG Display Server whenever a change occurs to the window
tree. Based on my last communication with Keith, and other factors, I
have for the past few months been prototyping and evaluating what I
had hoped would be a simpler approach which I call the "Z model." In
this design, the raw device events flow from the X server to the
Display Server, the 3D pick happens, and then the events are sent back
to the X server for grab processing. If the events are 3D events bound
for 3D apps then these events are sent back to the Display Server.
(I call it the "Z model" because if you look at the architectural
diagram, the stream of 3D events forms a "Z" as it goes between the
X server and the Display Server).

After investigating this design for several months I have come to the
conclusion that the Z model is inferior to my original
"grab-in-display-server" model for several reasons:

1. The path that 3D events take is more convoluted in the
   Z model. Events are bounced between the two processes
   like a badminton birdie. This affords more chances to
   introduce additional latency overhead.

2. In LG, 3D events (for various reasons) need to carry some
   information that results from the 3D pick information. This
   information is too voluminous to squeeze into an event, so
   I tried to store this information on the DS side and match it
   back up with the events when they return to the DS. I got
(Continue reading)

Permalink | Reply | 0 comments |
headers
Deron Johnson | 9 Nov 2004 22:09
Picon

Re: My design status

Amir Bukhari wrote:
> 
>>-----Original Message-----
>>From: xevie-bounces <at> freedesktop.org [mailto:xevie-bounces <at> freedesktop.org]
>>On Behalf Of Deron Johnson
>>Sent: Tuesday, November 09, 2004 8:55 PM
>>To: xevie <at> freedesktop.org
>>Subject: [Xevie] My design status
>>
>>Here is a status update on my thinking regarding the design of the LG
>>event system. Around August of this year I was pursuing a design in
>>which the grabbing was done in the Display Server. In order to achieve
>>this, topology changes to the window tree would be sent from the X
>>server to the LG Display Server whenever a change occurs to the window
>>tree. Based on my last communication with Keith, and other factors, I
>>have for the past few months been prototyping and evaluating what I
>>had hoped would be a simpler approach which I call the "Z model." In
>>this design, the raw device events flow from the X server to the
>>Display Server, the 3D pick happens, and then the events are sent back
>>to the X server for grab processing. If the events are 3D events bound
>>for 3D apps then these events are sent back to the Display Server.
>>(I call it the "Z model" because if you look at the architectural
>>diagram, the stream of 3D events forms a "Z" as it goes between the
>>X server and the Display Server).
>>
>>After investigating this design for several months I have come to the
>>conclusion that the Z model is inferior to my original
>>"grab-in-display-server" model for several reasons:
>>
>>1. The path that 3D events take is more convoluted in the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Deron Johnson | 11 Nov 2004 20:58
Picon

Question about synchronous grabs


Does anybody know what is the purpose of a synchronous grab in X?
Basically, a synchronous grab records incoming events while it is
active instead of sending them down the event pipeline. Only when
a client actively releases the synchronous grab does the event
pipeline start flowing again. And the recorded events are first played
back. So I know how synchronous grabs behave, but I'm not entirely
sure that I know what purpose they serve.

One purpose I can think of is to implement type-ahead (or mouse-ahead).
The user clicks a button which brings up a dialog. The button click
triggers a passive grab which is synchronous. The app then maps a
dialog window. After the window is up the app releases the synchronous
grab and any key events which the user has typed while the dialog
window was coming up will be sent to the dialog window.

Are there any other uses of synchronous grabs? How prevalent are
apps that use synchronous grabs? Does anyone know whether GNOME or
KDE use them?

The reason I ask is because synchronous grabs account of a significant
amount of complexity in the X server event code. I am questioning
whether it is worth trying to support these in my Display Server event
subsystem. The code is so complicated and involved that there are bound
to be transcription errors during any port.
Permalink | Reply | 3 comments |
headers
Jim Gettys | 11 Nov 2004 21:09
Picon
Favicon

Re: Question about synchronous grabs

Yes, you are onto why there are passive grabs in X...

Here's an example scenario for passive grabs:

You want to click on a window to set the focus, pop the window to the
top, and also want the event to set the input point in the input window;
you want subsequent typing to go to the "right place".

So the window manager might set a passive grab on a window, get the
event, set the input focus and restack the windows, and then AllowEvents
and replay the event to set the input focus to the "right place", and
the user keyboard events will go to the "right place" in the right
order.

This allows X to do various operations reliably even if applications are
not immediately responsive, and avoid a ton of race conditions.

You can think of passive grabs as "traps" waiting to be sprung, so that
events can always get delivered in the right order, despite the need for
other processing.

Unfortunately, many of the current toolkits do not exploit this
capability in X as much as they might/should.  Machines are no longer
so slow, but if you are paged out, they can still take measurable
amounts of time before applications are able to respond....
				- Jim

On Thu, 2004-11-11 at 11:58 -0800, Deron Johnson wrote:
> Does anybody know what is the purpose of a synchronous grab in X?
> Basically, a synchronous grab records incoming events while it is
(Continue reading)

Permalink | Reply | 2 comments |
headers
Deron Johnson | 13 Nov 2004 02:14
Picon

Re: Question about synchronous grabs

Thanks for the info, Jim.

I finally got around to looking at the types of grabs GNOME registers.
Unfortunately for me, it registers lots of synchronous grabs. This means
that I cannot simply ignore the synchronous grab cases while moving the
event processing into the LG Display Server. I'm going to need to risk
possible transcription errors and move the entire wad of event
processing stuff into the Display Server.

BTW, you mentioned to me at one time that you had done some work in
the X server event system before. How knowledgeable are you about
the workings of the synchronous grab logic. If not, is there anybody
still around who knows this stuff? It would be nice to have someone
review my port for correctness.

Jim Gettys wrote:
> Yes, you are onto why there are passive grabs in X...
> 
> Here's an example scenario for passive grabs:
> 
> You want to click on a window to set the focus, pop the window to the
> top, and also want the event to set the input point in the input window;
> you want subsequent typing to go to the "right place".
> 
> So the window manager might set a passive grab on a window, get the
> event, set the input focus and restack the windows, and then AllowEvents
> and replay the event to set the input focus to the "right place", and
> the user keyboard events will go to the "right place" in the right
> order.
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jim Gettys | 15 Nov 2004 18:43
Picon
Favicon

Re: Question about synchronous grabs

On Fri, 2004-11-12 at 17:14 -0800, Deron Johnson wrote:
> Thanks for the info, Jim.
> 
> I finally got around to looking at the types of grabs GNOME registers.
> Unfortunately for me, it registers lots of synchronous grabs. This means
> that I cannot simply ignore the synchronous grab cases while moving the
> event processing into the LG Display Server. I'm going to need to risk
> possible transcription errors and move the entire wad of event
> processing stuff into the Display Server.
> 

I don't think we can ignore passive grabs either.

I don't think that externalizing them will be a performance issue on
current machines, which are 100-1000x faster than in the past, so long
as the external applications don't get paged out.  The context switches
just don't take that long.

> BTW, you mentioned to me at one time that you had done some work in
> the X server event system before. How knowledgeable are you about
> the workings of the synchronous grab logic. If not, is there anybody
> still around who knows this stuff? It would be nice to have someone
> review my port for correctness.

I think it must have been Keithp who said this to you.  He's had his
fingers almost everywhere.

			Regards,
				- Jim
(Continue reading)

Permalink | Reply | 0 comments |
headers
Deron Johnson | 22 Nov 2004 19:54
Picon

Re: Question about synchronous grabs

Jim Gettys wrote:

>> I don't think we can ignore passive grabs either.

I agree. Support for passive grabs is absolutely required.
I've basically decided to do a surgical extraction of all of the
event pipeline code in dix/events.c and support all features, including
synchronous grabs. (Except I'm not going to initially support cursor
confinement or pointer warping, which I regard as being evil in a GUI,
but I can always add them in later). I plan to validate this
"event-otomy" by using it to construct an external event handling
process and using it to run GNOME. Once I am confident that nothing
is majorly broken I'll gradually convert it over to Java and stuff it
into the LG3D Display Server.
Permalink | Reply | 0 comments |

Gmane