jim@athsys.uucp (Jim Becker) (10/18/88)
Intro:
Before making this request, I want to state that I understand
the current pressure upon the MIT staff to get R3 out and
free of problems as quickly as possible. The request that I
am making is assumed NOT to be part of the next release of X,
but would be a worthwhile addition to the X package in the
future. I believe that I am aware of the ramifications of
backward-compatability and such, but believe that this future
enhancement of X could prove very useful for improving appli-
cation event processing throughput. I also assume that this
request has been thought of and made, although I have not
seen in come across the wire.
This request seems rather simple to introduce to the package,
and may already be in there somewhere, although I haven't
discovered it as of yet. It would greatly help me, and lots
of others, that are developing UIMS type packages for the X
windows standard. As my clients' needs get more complex, not
having this capability will simply slow down my ability to
minimize response time.
Background & Request:
There are a number of user interface packages and Widget sets
that are being created for the X windows platform. Most of
these are adopting an object oriented approach to the task,
OO being the latest buzzword in the industry.
The interface system managing the user events currently reads
the event stream, interprets the context of the event and
dispatches the appropriate software routines to do the han-
dling. For each event, the logic must determine the mapping
of the "window" field of the XEvent structure to the internal
data structures associated with the window. Once this con-
nection is made the software routines are dispatched.
Mapping of the XEvent window XID to the cooresponding data
structures and logic currently must be done within the logic
of the interface handling portion of the client program. This
normally involves some sort of tablular or linked-list lookup
within the resources of the client. Herein lies the overhead
of the event processing throughput.
More complex interfaces represent more windows and lookup,
hence more slowdown in determining the correct object of an
event. In certain instances this has led to re-writting of
the server or lookup algorithms to optimize this task. (I am
thinking of what I know of the DECwindows approach).
This lookup is currently within the server, to determine the
XID of the event being dispatched, as well as within the
client, to map the XID to the client data internals. It would
be nice to eliminate the redundancy from the client side of
the logic.
Elimination of this lookup logic is trivial. If there were
the ability for the client to associate a pointer with the
XID window resource this pointer could be returned along with
the XEvent structure. The pointer would be a generic "UserDa-
ta" field, and it was up to the client to define and inter-
pret this field. In an object-oriented world the pointer
would point to the object of the window, whatever data format
that was defined as being.
This capability would eliminate the need for additional logic
and overhead of the client process. It would improve
throughput of X and make it a cleaner/leaner machine to util-
ize. And it is pretty easy to add (no flames, please). With
the continuing complexity and demands of the software world,
this shortcut may help ease the creation of programs and more
easily define application interfaces.
Simple Statement of Request:
I tend to be a little verbose, what I am requesting is simply
a new "UserData" field that is settable for an XID window
resource. The specified "UserData" would be returned as a
field in the XEvent structure for use by the client program.
It would be a 32 bit field that was defined and understood by
the client only, with the server just passing the value
around.
Thanks for listening to yet another request. I hope this one can
make it in at some time, I think it would greatly help in the fu-
ture speed and complexity of X products.
-Jim Becker sun!athsys!jimjim@EXPO.LCS.MIT.EDU (Jim Fulton) (10/18/88)
Okay, I'll play devil's advocate: > Before making this request, I want to state that I understand > the current pressure upon the MIT staff to get R3 out and > free of problems as quickly as possible. Glad to hear it. :-) > The request that I > am making is assumed NOT to be part of the next release of X, Actually, the constraints on the MIT staff have almost nothing to do with whether or not something is added to the core protocol and libraries. All such extensions (especially ones that possibly involve incompatible changes to the protocol) must go through the Consortium before they even come close to the tape. > This lookup is currently within the server, to determine the > XID of the event being dispatched, as well as within the > client, to map the XID to the client data internals. It would > be nice to eliminate the redundancy from the client side of > the logic. It seems that all you'd be saving would be a hash table lookup. > The pointer would be a generic "UserDa- > ta" field, and it was up to the client to define and inter- > pret this field. In an object-oriented world the pointer > would point to the object of the window, whatever data format > that was defined as being. It would be an "arbitrary data" field, not a "pointer" (What are pointers anyway? And, how much space do you need to hold one? Hint: the answer isn't "32 bits"!). You'd probably want to have it obey the same swapping rules as properties. But, whether or not an application would choose to be unportable and store a real pointer in it depends on the semantics of setting the user data field. For example, is there a user data field for every client for every window? If not, what do you do when more than one application wants to stick something on the window? Does the last request (which is what, by the way: extend the core ChangeWindowAttributes or add a new request?) to change it win? Unfortunately, this means that multiple applications trying to set user data on a single window will get horribly confused (better not store store actual pointers in there...). Okay, so you could add a new UserDataChange event and either extend one of the existing event masks or add a new UserDataMask. Then, applications could get an event whenever the user data whenever the user data field gets changed, so that they can decide whether or not to pitch their cookies. But, this means that applications can't absolutely rely on the user data. Instead, they would have to treat the data as a hint to optimize lookup, but they would still need to have a hash table. Now, suspending belief for a second, perhaps we could add a GrabUserData request or another field which indicates whether or not the data field has been set. But, we now get into race conditions, timestamps, and other nastiness. Yuck. For something that started out trying to save applications a little bit of work, we're getting kind of hairy. > This capability would eliminate the need for additional logic > and overhead of the client process. But, by how much? You could well end up with more complexity than the simple hash table with a tiny cache. > Thanks for listening to yet another request. Being a forum for discussing new ideas is one of XPERT's primary goals. > I hope this one can > make it in at some time, I think it would greatly help in the fu- > ture speed and complexity of X products. In order for that to happen, somebody would need to generate a detailed proposal. If you are interested in pursuing this sort of extension, you will need to spend some time writing down exactly what the semantics are, what new requests, events, attributes, etc. would be necessary, and how it could be done so that existing clients would work with a new server without having to be relinked. Jim Fulton MIT X Consortium
garya@stan.com (Gary Aitken) (10/19/88)
There should be two pointers passed:
Address of a function to execute
Address of an argument (the object) for the function
Otherwise, you still end up having to do a lookup based on the event type.
Since the purpose of the proposal is to speed up the dispatch mechanism,
let's get the most we can out of it.garya@stan.com (Gary Aitken) (10/19/88)
> It seems that all you'd be saving would be a hash table lookup. True. But in an application with a lot of windows (and let's face it, many real applications are going to have hundreds of them), duplicating the hash table is going to gobble up a lot of memory. I'm guessing it will gobble a lot more memory than the cells wasted for those windows which won't have a "user_data" field specified for them, but someone should probably do some analysis of this before going forward with a proposal. > You'd probably want to have it obey the same swapping rules as > properties. But, whether or not an application would choose to be unportable > and store a real pointer in it depends on the semantics of setting the user > data field. I don't think this is true. Just as the event mask is associated with a particular client, and used only by that client, so is the proposed data field. The server would only carry it as baggage, with no inter- pretation, and would return it in the same form it was presented. If the server chose to swap bytes for some reason, it would be obligated to swap them back when generating the returned event structure. > For example, is there a user data field for every client for every window? I think the answer is yes, which means all the ChangeWindowAttributes problems go away. -- Gary Aitken ncar!boulder!stan!garya
mao@blia.BLI.COM (Mike Olson) (10/19/88)
i've done object-oriented windows for X11R2. although i like the extension proposed, a few points bother me: jim fulton is correct, in his response to the original message, when he states that hash table lookups are cheap. associating a little data with a window only saves you a little work. second, at some point, programmers have to program. the server may be able to do some bookkeeping for my application, but we need to be careful, as is evident here: > From: garya@stan.com (Gary Aitken) > There should be two pointers passed ... should there be n pointers passed? [actually, there should be zero pointers passed. the server should return some number of bits (32 or 64?) with the event. assuming that you've got enough bits for a pointer is a very bad idea (again, fulton is correct).] if the consortium decides to do something like this, they'll need to ignore most of us; i'd *really* like the server to return the piece of code i should execute, along with all parameters i should pass it, and maybe also the day of the week. finally, calling this an "object-oriented" extension is a mistake. you tell the server that window p has some bits pb associated with it, and ask the server to give you those bits when something happens to the window. the macintosh has done this from the days of the 128k closed box, and nobody pretended that *it* was object-oriented, back then. the meaning of the data depends on the application. i think that the original poster should consider jim fulton's comments, and submit a proposal. as i say, i like the idea, in general; there are problems, but they might be worth solving. i'm willing to discuss the pitfalls of object-oriented windows, but we should probably do so off-line. my email address appears below. mike olson britton lee, inc. ...!ucbvax!mtxinu!blia!mao
garya@stan.com (Gary Aitken) (10/20/88)
> should there be n pointers passed? ... Agreed, the generalization from 1 pointer to 2 could go on expanding and should send up all sorts red flags... I like the idea of an arbitrary number of bits (chars?), client definable. The server would then accept/return something like: short int n_bytes ; /* # bytes in client info */ char *client_data ; However, this then gets a bit contorted because the arbitrary data has to go down the wire. As you point out, the client could easily have an arbitrarily complex structure it needed to keep track of, and it is trying to use the server to give it a hint (no, better than that, an exact map) to which structure to use. Since this is client specific data, it seems a bit strange to use the server as a cache for it, which is the effect of storing an arbitrary number of bits. I'll withdraw my earlier plea for more than one pointer, and say one is enough. If the client has complex structures, it can ask the server to accept/return a ptr to the structure. In this model, it SHOULD be a pointer, not an arbitrary string of bits. The main problem with cacheing a pointer is that if the dispatch mechanism reallocates its tables when it expands them, the cached info is wrong. The client will have deal with that problem itself. > ... calling this an "object-oriented" extension is a mistake." Agreed. I don't care what you call it. The point is, ANY application is going to go through some dispatch mechanism after calling XNextEvent, and any information the server can provide to speed it up by reducing a duplication of function on the client side would be a help.