Date: Thu, 16 Mar 1995 14:12:09 EST From: "Kaleb S. KEITHLEY" <kaleb@x.org> To: hackers@FreeBSD.org Subject: Re: patches for X11R6?? Message-ID: <9503161912.AA12240@fedora.x.org> In-Reply-To: Your message of "Thu, 16 Mar 1995 10:15:56 MST." <9503161715.AA23508@cs.weber.edu>
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? >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. 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 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? >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. >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. -- Kaleb KEITHLEY X Consortium
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9503161912.AA12240>