jacobi.pa@XEROX.COM (08/19/88)
Some small proposals for the next round of protocol changes [X12?] Resource identifier allocations Problem: Most connections do not need all their 2**18 resource identifiers; they could use less resources for the benefit of others; some few connections might need more than 2**18 resources. [This occurs specially in systems which use a shared address space for different applications; where different applications might share one instance of the XLib-equivalent] Proposal: At connection set up a modest [much smaller] number of resource identifiers is allocated for the connection. When the connection seems to get out of resources it makes a request to be allocated more resources. Fake implementation and why this is bad. When connection gets out of resource identifiers it creates an additional connection; on all further resource creations the additional connection is used instead. However, this forces the resource creations to use a roundtrip request, to make sure the server has really allocated the resource before a request on the original connection refers to it. Small implementation problem: when either the original or the additional connection gets destroyed the other one has to follow. Time stamps and mappingNotify The mappingNotify event should have a time stamp. In my shared address space implementation different connections to the same server do share mappings in a common cache. A mappingNotify event flushes the cache for all those connections. I'd like to be able to recognize the mappingNotify events of different connections to be equal or not. This cache flushing can guarantee that no connection uses a mapping which is out of date, but it does not prevent from usage of a mapping which is to new for the particular connection. Related: Should there be a convention saying that the mapping does not change except rarely on server or window manager set up? Am I wrong here, and there is a case when mappings do change at other times? Maybe: Why not carry the server time with every event? The nothingHappened event [with timestamp] Problem: Double mouse clicks Double mouse clicks are recognized easy; just look at the time in between. But recognizing the absence of double mouse clicks is tricky: Before reporting a single mouse click, the program must wait a short time [using the server clock, in case of slow communications]. The server will won't report nothing happened. Fake implementation and why this is bad. Have the application change an otherwise unused property whenever no action was reported by the X server, using increasing time intervals. This is bad because it forces the application to monitor all events on the connection, to find out whether something happened or not; it also forces the input detection module to listen to property change events [which might be frequent]. Finally, this is sort of tricky application code, but it looks to me as it would be less tricky on the server side. Time out features E.g. GrabServer could use a timeout. There might or might not be also an timeOutEvent. GrabButton could use a "timeout feature" too, e.g if a certain key is pressed. However we might enter into policy here which key we are speaking about. A convention for destroy window for window managers is needed. Obviously a window manager is not allowed to simply destroy top level windows. [I tried it, and it generally did lead to server crashes if I did this to C programs]. The destroy connection request is not very practical when different applications share a common connection [e.g. in my shared address space implementation the norm]. I would appreciate a common convention or an event which tells the application to voluntarily destroy this window. [And using the destroy connection request as last resort only] I'd like to see an Interpress extension [Like "everybody" else]. Having an Interpress [or maybe Postscript, or, something similar] extension might enable the number of imaging requests to be supported to be reduced. Does somebody have statistics over which events and which requests use what fraction of the communication bandwith? Is there separate data for XLib, different toolkit or CLX applications? This might tell me what kind of information is worth caching and what not. Christian Jacobi Xerox PARC Jacobi.pa@Xerox.com
raveling@vaxb.isi.edu (Paul Raveling) (08/26/88)
In article <880818-131820-7122@Xerox> jacobi.pa@XEROX.COM writes: > >Some small proposals for the next round of protocol changes [X12?] Here's another modest suggestion, should there ever be an X12, or whatever... Small Color structures -- 8 bits per RGB component, and maybe even per pixel. Image quality improves measurably as the number of colors available increases, but to a human observer it takes careful study to find a difference past about 6 bits of resolution. Even 5 bits is pretty good. For this reason plus economics, I believe 8 bits is a reasonable practical value for the maximum resolution anyone is likely to build into display hardware. It's less clear that 8 bits is sufficient as a pixel index, but 16 should be practical. Some of our image processing utilities need one copy of an image which would best be represented by a Color structure and another which can be mainly an array of pixel values. When the image size is around a megapixel, using the current Color structure can generate a couple malloc's for a total pushing 15 megabytes in two blocks. Not many of our workstations can handle that sort of memory load. A Colors and pixels that are smaller by a factor of 2 would be welcome. --------------------- Paul Raveling Raveling@vaxb.isi.edu