From owner-freebsd-hackers Thu Mar 16 17:26:27 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id RAA08126 for hackers-outgoing; Thu, 16 Mar 1995 17:26:27 -0800 Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id RAA08120 for ; Thu, 16 Mar 1995 17:26:26 -0800 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA26263; Thu, 16 Mar 95 18:20:15 MST From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9503170120.AA26263@cs.weber.edu> Subject: Re: patches for X11R6?? To: kaleb@x.org (Kaleb S. KEITHLEY) Date: Thu, 16 Mar 95 18:20:14 MST Cc: hackers@FreeBSD.org In-Reply-To: <9503161912.AA12240@fedora.x.org> from "Kaleb S. KEITHLEY" at Mar 16, 95 02:12:09 pm X-Mailer: ELM [version 2.4dev PL52] Sender: hackers-owner@FreeBSD.org Precedence: bulk > >> 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.