merritt@max.u.washington.edu (02/01/91)
Please reply via Email; in desparation I am posting to groups which I don't normally read! Plea: I have just gotten a DECstation 5000/200PXG up and [sort of] running, but have run into a blank wall when it comes to using it for displaying images (which is after all what I bought it for!). Can anyone out there help with the following questions? Major problem: - This is a 24 plane display with Z-buffer, but I can't for the life of me find a demo/example/code_fragment/writeup/whatever that shows me how to get a true color (24bit) picture up on the screen. I.e., I want to specify 8 bits of red, 8 bits of green, and 8 bits of blue for each pixel in a window directly (no color maps). Eventually I will be writing applications code which needs to display such pictures, but for the moment I'd settle for looking at images I've created on an IRIS and stored in a binary file (I can dump in a number of formats, including sun rasterfiles). Surely there's a utility equivalent to ipaste on the IRIS????? - The manual pages for the X11 utilities all speak explicitly of colormaps, which I do NOT want to use. The xdpyinfo utility reports that my display has depth of 24 bits (correct) and lists "visuals" with classes DirectColor and TrueColor, but even these are listed as having a colormap size of 256. This doesn't seem right, and anyway none of the X library routines which I can find in the documentation seem of any help when it comes to describing individual pixels. Are these in the X3D-PEX extensions - and if so is there any documentation anywhere for what and where they are? - Maybe this has to be done outside of X altogether? But then where do I start? Less major problems: - The DEC postscript viewer dxpsview fails on every postscript file I have tried with the X error: "BadAlloc (insufficient resources for operation) opcode 53 (X_CreatePixmap)" I get the same error on other DECstations (5000/200PX) as well. Is this a bug in the Ultrix 4.1 release? Is there a work-around (maybe another more generic X-based postscript viewer)? - I was quite taken aback to find that the 19" Sony monitor has two dark horizontal lines across it (about 1/3 and 2/3 of the way down the screen). I thought this was a hardware problem, but after a visit from the field service people I was told "They're all like that. That's what makes the Sony monitors so good - they use those lines to keep the electron beam precisely in register"! Am I the only one in the world to be disturbed by extra lines across my screen? And what about taking photos from the screen (I can't afford a separate film recorder) - who wants extra horizontal lines on what's supposed to be a high-resolution 24-bit color presentation slide? Anyone have any comments on this - like should I give up on it or try to make DEC find me a monitor without the extra lines? thanks for anything you can offer, Ethan A Merritt -------------------------------------------------------------------------------- Dept of Biological Structure H510 Health Sciences University of Washington SM-20 (206)543-8865 Seattle, WA 98195 merritt@u.washington.edu --------------------------------------------------------------------------------
xpert@hydro.saic.COM (xpert_news) (02/02/91)
merritt@max.u.washington.edu write about DecStation 5000 PX's Sony Monitors: >- I was quite taken aback to find that the 19" Sony monitor has two dark > horizontal lines across it (about 1/3 and 2/3 of the way down the screen). I > thought this was a hardware problem, but after a visit from the field service > people I was told "They're all like that. That's what makes the Sony monitors > so good - they use those lines to keep the electron beam precisely in > register"! Am I the only one in the world to be disturbed by extra lines > across my screen? And what about taking photos from the screen (I can't > afford a separate film recorder) - who wants extra horizontal lines on what's > supposed to be a high-resolution 24-bit color presentation slide? > Anyone have any comments on this - like should I give up on it or try to make > DEC find me a monitor without the extra lines? I too am equally annoyed!!!!! I have had three monitors. However, this is not the only place where DEC's engineers have made serious enough judgement errors that after having bought many DEC workstations in the past, I may not be willing to buy even one in future. Another serious problem with the Decstation 5000/PX appears to be its extremely poor performance on some imaging applications such as the XDataSlice. For such applications teh 5000/PX is decidedly inferior to a Decstation 3100 rnning MIT's X11R4 server. I have received e-mail message from a dozen users of DS 5000/PX from throughout the North America confirming my observations. SOme DEC engineers have suggested to me to purchase the lower-end model CX. I only wish that DEC salespersons had told me of about this recommendations Vijay S. Tripathi Internet: vijay@hydro.saic.com Director Contaminant Transport Research SAIC 1710 Goodridge Drive McLean, VA 22102
mouse@lightning.mcrcim.mcgill.EDU (02/06/91)
> I have just gotten a DECstation 5000/200PXG up and [sort of] running, > but have run into a blank wall when it comes to using it for > displaying images (which is after all what I bought it for!). > Major problem: > - This is a 24 plane display with Z-buffer, but I can't for the life > of me find a demo/example/code_fragment/writeup/whatever that shows > me how to get a true color (24bit) picture up on the screen. The core X protocol can deal with the 24-bit part just fine, but you'll need an extension to get X access to the Z-buffer. But for what you want at the moment you don't need the Z-buffer anyway. > I.e., I want to specify 8 bits of red, 8 bits of green, and 8 bits > of blue for each pixel in a window directly (no color maps). > - The manual pages for the X11 utilities all speak explicitly of > colormaps, which I do NOT want to use. In X, `colormap' is a technical term. In that sense of the word, you do want to use them; all X displays do, even one-bit black and white displays. In your case, you want a colormap created on the DirectColor or TrueColor visual; from what you said above, I think you want the TrueColor one. Here is what the protocol document has to say: For DirectColor, a pixel value is decomposed into separate RGB subfields, and each subfield separately indexes the colormap for the corresponding value. The RGB values can be changed dynamically. TrueColor is treated in the same way as DirectColor except the colormap has predefined read-only RGB values. These values are server-dependent but provide linear or near-linear increasing ramps in each primary. > The xdpyinfo utility reports that my display has depth of 24 bits > (correct) and lists "visuals" with classes DirectColor and > TrueColor, but even these are listed as having a colormap size of > 256. This is normal. The colormap size for TrueColor and DirectColor will "usually" [quote from the protocol document] be 2 to the power of the largest color's number of bits - in your case, each primary has 8 bits, so you can expect 2^8 as the "size" of the colormap. What you want to do is, + Use XMatchVisualInfo to find a 24-bit TrueColor visual. + If it's the default visual, use the default colormap; if not, create a colormap for it. + Create a window with the visual and colormap you just found. + Construct your 24-bit pixel values by using the red-mask, green-mask, and blue-mask values for the Visual to plug your RGB values into a 24-bit word. Here is the protocol document's description of these three mask values: The red-mask, green-mask, and blue-mask are only defined for DirectColor and TrueColor. Each has one contiguous set of bits set to 1 with no intersections. Usually each mask has the same number of bits set to 1. If you have only a few colors to use and don't want to mess with figuring out the shifts and masks you need, you can just XAllocColor for each color. + Display your stuff! der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
Chris.Rusbridge@levels.sait.edu.au (02/08/91)
In article <9102020056.AA25076@hydro.Saic.COM>, xpert@hydro.saic.COM (xpert_news) writes: > > Another serious problem with the Decstation 5000/PX appears to > be its extremely poor performance on some imaging applications > such as the XDataSlice. For such applications teh 5000/PX is > decidedly inferior to a Decstation 3100 rnning MIT's X11R4 > server. > > I have received e-mail message from a dozen users of DS 5000/PX > from throughout the North America confirming my observations. > We have reports from at least two software companies of serious graphics performance difficulties with their ports to DECstation 5000s with the PX (8 bit plane) and PXG 24 bit plane options. We have a large number (>20) of DECstation 5000s on order. Most are equipped with PX (8-plane) accelerated graphics, and several with PXG graphics plus 24 planes. These machines were intended to run the software in question, among other software, and the reports are causing us serious concern. We would very much appreciate any advice from users with actual experience of these PX and PXG 24 bit plane options, to help us work out how to respond. One image processing software company claims the PXG 24 plane "board design is flawed when trying to display raster data. DEC is seriously considering an alternative 24 bit plane native display... it is highly likely that the PXG in an 8 bit mode would not be acceptable". Another company reports their product "will not run okay in 8 bit mode using DEC 24 bit card". We also have reports from the second of these companies of poor graphics performance with the PX board. The performance with the PX option is "definitely less than that of the CX option or even of the DECstation 3100". Other comments indicate that the degradation is from 30 seconds with CX to 20 minutes with PX, and that attempted workarounds were unsuccessful. The majority of performance problems seemed to be related to XDrawSegments and XFillPolygon. Chris Rusbridge Academic Computing Service Manager (City, Levels and Whyalla campuses) University of South Australia AARNet: Chris.Rusbridge@sait.edu.au Phone: +61 8 343 3098 Fax: +61 8 349 4213 Post: The Levels, SA 5095 Australia
jensen@wrl.dec.com (Paul Jensen) (02/08/91)
>We would very much appreciate any advice >from users with actual experience of these PX and PXG 24 bit plane >options, to help us work out how to respond. By all means communicate with other users, but be sure 1) that their application is similar enough to yours for comparisons to be valid; 2) to filter out unsubstantiated reports of problems, problems with low information content, and problems which have been corrected in subsequent releases. The rendering chips used in the PX[G] options were designed primarily to accelerate 2D & 3D drawing operations (points/lines/triangles). For the most common cases (e.g. 0-width solid lines), these primitives are 2-4 times faster than the DS3100 (as measured by X11perf), while using fewer host cycles. Applications depending on XDrawSegments or XFillPolygon should run at hardware speed: I would be interested (as one of the principals of the PX[G] server port) in hearing *specific details by mail* about cases where this is not true. Imaging is more of a problem, because of two limitations in the PX[G] hardware: pixel-level access to the frame buffer is slower than the cfb options; and there are only 1.3-3.9 Mpix of offscreen memory available. Contention for offscreen memory (which can be caused by cycling through a large set of pixmaps) is usually a worse problem than the slower access to the frame buffer. This does not imply that image display on the PX[G] is necessarily unacceptable: it does mean that achieving peak performance requires more care, and there are definitely some tar pits to avoid. Tuning graphics software is a tricky business, requiring knowledge of many factors, including the primitive mix, and the ratio of graphics to non-graphics computation. Some time back I wrote a white paper discussing hardware differences between the PX and "dumb" frame buffers, and coding ramifications thereof. Much of what I said there also applies to the PXG. Even if you are not actively developing grahics software, you may find this useful. You should be able to get a copy from your DEC sales rep: the title of the paper is "A Guided Tour of the PX Graphics Option" (or some close approximation). I would suggest that followups be directed to comp.sys.dec, or conducted by mail, in order to keep this newsgroup from growing beyond its present unmanageable :-) size. -- /Paul Jensen Digital Equipment Corp. Palo Alto, CA
allen@wrl.dec.com (Allen Akin) (02/08/91)
In article <15870.27b18964@levels.sait.edu.au> Chris.Rusbridge@levels.sait.edu.au writes: >In article <9102020056.AA25076@hydro.Saic.COM>, xpert@hydro.saic.COM >(xpert_news) writes: > >We have reports from at least two software companies of serious >graphics performance difficulties with their ports to DECstation 5000s >with the PX (8 bit plane) and PXG 24 bit plane options. > >... Paul Jensen replied to this note in comp.windows.x, but his reply was not cross-posted. Here it is: >From: jensen@wrl.dec.com (Paul Jensen) >Subject: Re: How to get 24-bit pictures on DECstation 5000/200PXG? >Message-ID: <1991Feb7.221431.9199@pa.dec.com> >Keywords: DECstation PX PXG 24planes >Organization: DEC Advanced Technology Development, Palo Alto, CA >References: <9102020056.AA25076@hydro.Saic.COM> <15870.27b18964@levels.sait.edu. >au> >Date: Thu, 7 Feb 91 22:14:31 GMT >Lines: 48 > >>We would very much appreciate any advice >>from users with actual experience of these PX and PXG 24 bit plane >>options, to help us work out how to respond. > >By all means communicate with other users, but be sure >1) that their application is similar enough to yours for comparisons >to be valid; 2) to filter out unsubstantiated reports of problems, >problems with low information content, and problems which have been >corrected in subsequent releases. > >The rendering chips used in the PX[G] options were designed primarily >to accelerate 2D & 3D drawing operations (points/lines/triangles). >For the most common cases (e.g. 0-width solid lines), these primitives >are 2-4 times faster than the DS3100 (as measured by X11perf), while >using fewer host cycles. Applications depending on XDrawSegments >or XFillPolygon should run at hardware speed: I would be interested >(as one of the principals of the PX[G] server port) in hearing >*specific details by mail* about cases where this is not true. > >Imaging is more of a problem, because of two limitations in the >PX[G] hardware: pixel-level access to the frame buffer is slower >than the cfb options; and there are only 1.3-3.9 Mpix of offscreen >memory available. Contention for offscreen memory (which can >be caused by cycling through a large set of pixmaps) is usually >a worse problem than the slower access to the frame buffer. >This does not imply that image display on the PX[G] is necessarily >unacceptable: it does mean that achieving peak performance >requires more care, and there are definitely some tar pits to avoid. > >Tuning graphics software is a tricky business, requiring knowledge >of many factors, including the primitive mix, and the ratio of graphics >to non-graphics computation. Some time back I wrote a white paper >discussing hardware differences between the PX and "dumb" frame buffers, >and coding ramifications thereof. Much of what I said there also applies >to the PXG. Even if you are not actively developing grahics software, >you may find this useful. You should be able to get a copy from your DEC >sales rep: the title of the paper is "A Guided Tour of the PX Graphics >Option" (or some close approximation). > >I would suggest that followups be directed to comp.sys.dec, or conducted >by mail, in order to keep this newsgroup from growing beyond its present >unmanageable :-) size. > >-- > /Paul Jensen > Digital Equipment Corp. > Palo Alto, CA I'd add the following observations: There is no difference in rendering or image-display performance between the 8-plane PXG and the 24-plane PXG. There is very little difference in 2D graphics performance between the PX and PXG. 8-plane applications run perfectly well on 24-plane PXGs, as long as they don't make unfounded assumptions (for example, assuming that the default visual type is 8-plane pseudocolor). Check out Paul's paper to understand the differences between PX and CX performance. We've certainly never seen a 40-to-1 performance degradation such as the one you cite. If you still have contacts at the developer, please refer them to Paul or me. Allen Akin
hudacko@ecevl1.enet.dec.com (Ted SCUDako) (02/09/91)
In article <9102060022.AA04657@lightning.McRCIM.McGill.EDU>, mouse@lightning.mcrcim.mcgill.EDU writes: |> Path: ncsuvx!lll-winken!uwm.edu!wuarchive!zaphod.mps.ohio-state.edu!usc!snorke elwacker.mit.edu!bloom-beacon!dont-send-mail-to-path-lines |> From: mouse@lightning.mcrcim.mcgill.EDU |> Newsgroups: comp.windows.x |> Subject: Re: How to get 24-bit pictures on DECstation 5000/200PXG? |> Message-ID: <9102060022.AA04657@lightning.McRCIM.McGill.EDU> |> Date: 6 Feb 91 00:22:56 GMT |> Sender: daemon@athena.mit.edu (Mr Background) |> Organization: The Internet |> Lines: 73 |> In your case, you want a colormap created on the DirectColor or |> TrueColor visual; from what you said above, I think you want the |> TrueColor one. |> |> + Use XMatchVisualInfo to find a 24-bit TrueColor visual. |> |> + If it's the default visual, use the default colormap; |> if not, create a colormap for it. |> |> + Create a window with the visual and colormap you just found. |> |> + Construct your 24-bit pixel values by using the red-mask, green-mask, |> and blue-mask values for the Visual to plug your RGB values into a |> 24-bit word. Here is the protocol document's description of these |> three mask values: |> The red-mask, green-mask, and blue-mask are only defined for |> DirectColor and TrueColor. Each has one contiguous set of bits |> set to 1 with no intersections. Usually each mask has the same |> number of bits set to 1. |> If you have only a few colors to use and don't want to mess with |> figuring out the shifts and masks you need, you can just XAllocColor |> for each color. |> I'm working on displaying 2D raster graphics on a 24bit-plane TrueColor DECstation 5000/200 and this discussion and suggestion seems pretty much to correlate with what I've been doing. However, using the XAllocColor() routine for every pixel in your image makes things really slow. Ted Hudacko