moss@brl.mil (Gary S. Moss (VLD/VMB) <moss>) (02/07/91)
I've just finished modifying Rob Pike's "sam" editor to work on X servers whose default visual is other than 1 bit deep. As far as I could tell from the Xlib routines, the X server under IRIX 3.3.1 does not support a 1 bit deep visual, only an 8 bit visual. I generalized the code to use a multiple bit deep visual when a 1 bit visual is not available, however the result is way too slow to be usable on the SGI 240/GTX. Not only is XCopyPlane() required to tranform textures and cursor bitmaps into 8 bit pixmaps, but 8 times as much data needs to be sent to the server whenever anything is drawn. I realize that part of the problem is that sam uses a low-level interface to the Xlib routines in order to emulate the DMD graphics routines. For instance, the bitblt routine uses XCopyArea(), but this is lightning fast on monochrome *and* color Suns. Given that the SGI GL and supporting hardware was not designed with bitblt-style operations in mind, has the X server been optimized to do the best it can on the 4D platforms? Does anyone at SGI know if any plans exist for resolving this performance issue in IRIX 4.0? Thanks, -Gary
jim@baroque.Stanford.EDU (James Helman) (02/07/91)
There are some problems with alignment and drawing 1 bit deep visuals that existed in 3.2 through 3.3.1 X servers. It is possible to partially kludge around the problem by rewriting the Xlib routine you are using. Not pretty. But in an emergency, I did this for XPutImage(). A much better option is to see if SGI can supply a fixed server. SGI was aware of the problem when 3.3.1 came out. We don't have 3.3.2, but a fixed server might have been included. I think we're all looking forward to wonderful things in 4.0. Does anyone know how X fares on the VGX? Is raster op performance better? Jim Helman Department of Applied Physics Durand 012 Stanford University FAX: (415) 725-3377 (jim@KAOS.stanford.edu) Work: (415) 723-9127
jsw@xhead.esd.sgi.com (Jeff Weinstein) (02/07/91)
In article <15113@smoke.brl.mil>, moss@brl.mil (Gary S. Moss (VLD/VMB) <moss>) writes: > Not > only is XCopyPlane() required to tranform textures and cursor bitmaps > into 8 bit pixmaps, but 8 times as much data needs to be sent to the server > whenever anything is drawn. I don't understand the above comments. Your bitmaps should be stored in the X server as 1 bit pixmaps, then copied to the screen using XCopyPlane() from the 1 bit pixmap to the 8 bit window. The hardware actually gets 1 bit of data per pixel and automatically expands it to 8. There is no reason for any 8 bit per pixel data to be sent anywhere in this scenario. > I realize that part of the problem is that sam uses a low-level interface > to the Xlib routines in order to emulate the DMD graphics routines. For > instance, the bitblt routine uses XCopyArea(), but this is lightning fast > on monochrome *and* color Suns. Given that the SGI GL and supporting > hardware was not designed with bitblt-style operations in mind, has the X > server been optimized to do the best it can on the 4D platforms? In the 3.* releases of IRIX the X server has not been tuned to take full advantage of the hardware. It has been constrained by having to be both a NeWS and GL client program. This results in many layers of software, and much useless data copying. > Does anyone at SGI know if any plans exist for resolving this performance > issue in IRIX 4.0? Just about all X performance problems are being resolved in IRIX 4.0. CopyPlane should perform well. We have seen dramatic speedups in many common X operations. --Jeff Jeff Weinstein - X Protocol Police Silicon Graphics, Inc., Entry Systems Division, Window Systems jsw@xhead.esd.sgi.com Any opinions expressed above are mine, not sgi's.
jsw@xhead.esd.sgi.com (Jeff Weinstein) (02/07/91)
Sorry, in my last followup on this subject I forgot to answer the real question, which was would we support a 1 bit visual. The answer is no, since we don't have any 1 bit hardware. X primitives such as copy plane should be fast enough in IRIX 4.0 that it is not necessary to support a 1 bit visual anyway. --Jeff Jeff Weinstein - X Protocol Police Silicon Graphics, Inc., Entry Systems Division, Window Systems jsw@xhead.esd.sgi.com Any opinions expressed above are mine, not sgi's.
moss@brl.mil (Gary S. Moss (VLD/VMB) <moss>) (02/07/91)
In article <1991Feb7.055317.21805@odin.corp.sgi.com>, jsw@xhead.esd.sgi.com (Jeff Weinstein) writes: |> In article <15113@smoke.brl.mil>, moss@brl.mil (Gary S. Moss (VLD/VMB) |> <moss>) writes: |> > Not only is XCopyPlane() required to tranform textures and cursor bitmaps |> > into 8 bit pixmaps, but 8 times as much data needs to be sent to the server |> > whenever anything is drawn. |> |> I don't understand the above comments. Your bitmaps should be stored in |> the X server as 1 bit pixmaps, then copied to the screen using XCopyPlane() |> from the 1 bit pixmap to the 8 bit window. Correct. |> The hardware actually gets 1 |> bit of data per pixel and automatically expands it to 8. There is no reason |> for any 8 bit per pixel data to be sent anywhere in this scenario. Admittedly, I'm naive about the internal workings of the Xlib routines and X server, so I'll take your word on the data transfer part, I guess I was just trying to rationalize the *extreme* slowness. However, I imagine that XCopyPlane() is significantly slower than XCopyArea() which is *really* slow on the SGI. If, as you say, SGI makes these routines suitably fast, it still doesn't make 1 bit visuals redundant. It would be cleaner to code programs that only deal with 1 bit deep images (like text editors) if one could assume that all servers support 1 bit visuals; I am not cognizant of the technical issues that might come up in implementing a 1 bit visual on hardware that doesn't support 1 bit raster ops, but it's something to consider. From my naive perspective, it seems that the details of dealing with the 1 bit to 8 bit conversion could be handled by the server in software if the hardware was not helpful in this regard. Perhaps this is not compatible with the X server model. I hope that this doesn't sound like a complaint; SGI seems to be moving swiftly with X, I'm just attempting to offer constructive suggestions. Thanks for the info, -Gary
jym@sgi.com (Administration Training Course) (02/07/91)
In article <15113@smoke.brl.mil> moss@brl.mil writes: >I realize that part of the problem is that sam uses a low-level interface >to the Xlib routines in order to emulate the DMD graphics routines. For >instance, the bitblt routine uses XCopyArea(), but this is lightning fast >on monochrome *and* color Suns. Given that the SGI GL and supporting >hardware was not designed with bitblt-style operations in mind, has the X >server been optimized to do the best it can on the 4D platforms? > >Does anyone at SGI know if any plans exist for resolving this performance >issue in IRIX 4.0? Absolutely. We are bring up X native(No NeWS) in Irix 4.0. Performance will improve a great deal. thanks, jim t (jym@esd.sgi.com)
karlton@fudge.wpd.sgi.com (Phil Karlton) (02/08/91)
The X protocol does require that all servers support 1 bit deep PIXMAPs (often referred to as a bitmap in the X community as well as elsewhere). PIXMAPs are like WINDOWs in the sense that they are DRAWABLEs meaning that any of the X rendering calls will work to any of them. There is no requirement that there be a 1 bit deep visual. In fact, I know of no server that supports both 1 bit deep visuals and deeper visuals to the primary frame buffer. It is legal for a server to do so, and I am sure there must be an implementation that does it. The Irix 4.0 server will have an optimised path for doing a CopyPlane from a bitmap to an appropriate depth window on the screen. For some of our hardware, this operation will be limited by the data paths to the frame buffer. There is no reason why CopyPlane from a bitmap should run any slower than CopyArea from a deep PIXMAP. CopyArea from WINDOW to WINDOW might entail crossing the frame buffer data paths twice. PK