Re: [9fans] always go for overkill, err vismon

[andrey mirtchovski <mirtchov@cpsc.ucalgary.ca>]

My setup includes the following machines (listed with available ram):

    1.7GB ram cpu server
    512MB ram cpu server
    160MB ram terminal running in vmware

on all those machines, either sitting behind the terminal, connecting via
drawterm or running in a vnc session I get exactly the same behaviour when
reading Boyd's jpg scan -- namely "page file.jpg" fails with:

    warning: couldn't read image: readimage: image too wide for buffer

on the other hand jpg -c file.jpg | page works! turns out that page uses

    jpg -t9 file.jpg

to convert the image to Plan 9 format. looking at the man page for jpg:

          -c   Convert the image to a Plan 9 representation, as
               defined by image(6), and write it to standard output.

          -9   Like -c, but produce an uncompressed image.  This saves
               processing time, particularly when the output is being
               piped to another program such as page(1), since it
               avoids compression and decompression.

          -t   Convert the image, if it is in color, to a true color
               RGB image.

the files that result from the conversion of Boyd's image have the
following sizes:

    --rw-rw-r-- M 1178 andrey andrey  1676944 Jan 16 10:09 c.bit
    --rw-rw-r-- M 1178 andrey andrey 22857190 Jan 16 11:17 9.bit
    --rw-rw-r-- M 1178 andrey andrey 68571450 Jan 16 11:13 t.bit

(ordered by option used -- -c -9 and -t9 respectively). readimage() can
handle the first two even on my puny 160mb vmware terminal but chokes on
the third one...

a possible solution is to use Memimage instead of Image -- readmemimage()
can apparently handle even the biggest of the three. I have hacked page to
use memimages, displaying only a part that is clipped by the screen
coordinates. there are ways to be smart about how much of the image is
loaded at any time, but it'll require more than a late afternoon of thinking and
a morning of tinkering. the conversion between Memimage and Image is non trivial
and it'll be great if we had a couple of library routines we could use to
draw from one onto the other (or maybe i fail to see them in the man
pages). the way it's done in the hacked page is to writememimage() to
one end of a pipe and readimage() from the other.

all of this impacts performance negatively, of course :)

andrey