Date: Thu, 16 Mar 95 18:20:14 MST From: terry@cs.weber.edu (Terry Lambert) To: kaleb@x.org (Kaleb S. KEITHLEY) Cc: hackers@FreeBSD.org Subject: Re: patches for X11R6?? Message-ID: <9503170120.AA26263@cs.weber.edu> In-Reply-To: <9503161912.AA12240@fedora.x.org> from "Kaleb S. KEITHLEY" at Mar 16, 95 02:12:09 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> >> If you compile with XLIB_ILLEGAL_ACCESS defined, then struct _XDisplay > >> is defined in Xlib.h. Code that requires this is not portable. > > >Apparently there has been an opaquing of several structs in the > >latest X release, including the GC. > > I'm not sure what those would be. Would you care to elaborate? The GC, for one, the display (under discussion) for another. Basically, everything protected by "*_ILLEGAL_ACCESS" that didn't used to be protected that way. This is not a general complaint, only a noting of fact. > >I don't necessarily agree with all of the changes in this direction, > >since there is a significant loss in speed in the additional function > >call overhead for reading GC pixel value contents, for instance. If > >done on a SPARC processer, this in fact forces a push of the entire > >stack frame (SPARC does this each four calls), which is a *very* > >significant hit. 8-(. > > Considering it takes about 0.5 usec to make a one argument function call > on a SPARC 10 with debug turned on, and about 0.2 usec with optimization > turned on, I think you'd have to make a lot of GC function calls to incur > a significant hit. This is assuming that the stack frame is not pushed. In my particular case, I was force from a call depth of 8 to a call depth of 9. The SPARC pushes the frame once for every 4th+1 level of call depth. > I would argue that you're doing something wrong if you're retrieving data > from the GC-struct frequently. I'm sure you can think of alternative > strategies to avoid excessive function calls if that's really your > performance bottleneck. I was using it for information hiding in a push-down, where I have a GC, call something to modify it, and it calls a common routine that is variant based on the GC Foreground pixel value. > >I can understand them not wanting you to write the values directly > >because of "server" side caching, but not wanting you to read > >them makes little or no sense. > > ``"server" side caching''? In the client? In the "X server". If you cache changes in the X server but don't update the in core copies until a defined interface based reference, you can get a bunch of wire traffic optimization. This is especially true if you have a struct that contains a bunch of stuff gathered from a bunch of different structs used for the implementation. The point of the GC (as opposed to the display) is that the GC is pretty much write-through caching in the X library for the client application, whereas some elements of the display structure would create a cache coherency problem if they were considered to be similarly cached. Timestamps, for one. > >The "_ILLEGAL_ACCESS" for the GC is not backward compatible in any > >case, since there are (gratuitous) changes to the layout of the > >structure contents (elements are renamed). > > X11 is a standard just like ANSI/ISO C and IEEE POSIX. The X Consortium > members specified the GC and Display structures, and the Sample > Implementation is a reflection of the standard. The changes were not > gratuitous, they were made with the full knowledge and approval of the > members of the X Consortium. That's why it's in parenthesis -- it represents my opinion (the second item in parenthesis represents what, in my opinion, was gratuitously changed. 8-). > >There is a major difference between interface abstraction and the > >rigorous enforcement of abstraction boundries. > > Which is not a valid rationalization for leaving a bug in the sample > implementation; especially if it's a bug that encourages people to write > inherently non-portable programs. The R5 Xlib.h warned people not to use > the fields in these structures, and these fields aren't listed in the > documentation. The only way they could have found out about them was by > reading the header file, so if they've been writing non-portable programs, > they can't say they weren't warned. Well, I think it should be honor system but whatever. 8-). It was for a game... can I be forgiven? Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9503170120.AA26263>