Re: MOSAIC problem (GIF image)


"George Cook" <cook@xxxxxxxxxxxxxxxx> wrote in message
news:cIeyPZoRhAEw@xxxxxxxxx
In article <43F31CEA.6D37E8A3@xxxxxxxxxxxx>, JF Mezei
<jfmezei.spamnot@xxxxxxxxxxxx> writes:
http://www.nwtel.ca/images/operatingArea/mapFull.gif

On Mosaic 3.8 VAX, the image doesn't show, I get a rectangle with the
mosaic logo and the name of the sys$scratch temporary file.

Any reason why Mosaic can't handle this particular GIF image ?

Works fine for me, but its size (1200x780) may be causing the
problem. Mosaic has both automatic (hardware) and parameter
image size limits. What display card are you using? What are
the preference settings for MAXPIXMAPWIDTH and MAXPIXMAPHEIGHT?
If MAXPIXMAPWIDTH and MAXPIXMAPHEIGHT are both zero, then the
automatic hardware limits have kicked in. Some display cards
limit the size of pixmaps to the dimensions of the display.

Unfortunately the documention (from HP/Compag/DEC) on which cards
are limited this way doesn't exist as far as I can tell, so Mosaic
has to attempt to detect the problem on the fly.


The limit for all VAX graphics except the LCG (VS4000 built-in graphics) is
the amount of available offscreen memory, which since this varies by device
and by resolution settings isn't easy to be specific about. The rule for
VAX graphics was there had to be enough offscreen memory available to
allocate a pixmap of the same size as the screen. The VS4000 can use "real"
system memory as offscreen memory, so on it the size can be adjusted by some
obscure logical name.

The historical reason for this was the belief that drawing to PIXMAPs needed
to be fast (as fast as drawing to the screen) by the DECwindows developers
(during X11R1-beta timeframes). The rest of the world decided that using
CFB for PIXMAPS was good enough - which makes the limit server virtual
memory address space. When we ported to Alpha, we joined the rest of the
world.




.