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 --------------------------------------------------------------------------------
jensen@wrl.dec.com (Paul Jensen) (02/05/91)
> > Please reply via Email; in desparation I am posting to groups which >I don't normally read! > You raise a few points of sufficiently global interest to be worth posting here. > [how to display truecolor images] The short answer is that what you want to do is fairly simple with core X (no PEX needed), but may not be necessary unless you enjoy programming. Image display software is everybody's favorite first X program, and as a consequence there are "billions and billions" of them floating around. The chances are what you want already exists: you should check comp.sys.sgi and comp.sources.x. If you have to roll your own, write your code to put the image into a matrix of ints (i.e. 32-bit pixels, 8 each of RGB), then read up on how to use the XPutImage call. You can't avoid colormaps, but unless you need Gamma correction the default on the 24-plane systems will serve you fine. >- Maybe this has to be done outside of X altogether? X (+ extensions) is the only way to gain access to the PX[G[-turbo]] graphics hardware. The X server uses undocumented driver ioctls() to gain access to undocumented hardware interfaces. >- 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)? > This is a "feature", documented in the release notes. DPS is trying to create an 8-1/2x11 pixmap; offscreen memory is not tall enough to accomodate this. The release notes document a workaround involving the "watch progress" option (which causes dxpsview to render directly to the window). You can also adjust the scale factor (<.9 ought to work) or orientation (i.e. landscape) menu options. My favorite is to start the server with the "-dpi 92" command line option: unlike the other workarounds, this one lets you say "dxpsview file" without having to mess around with the menues (92 dpi is closer to the resolution of most Sony monitors than 100 anyway). -- /Paul Jensen Digital Equipment Corp. Palo Alto, CA
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