From mboxrd@z Thu Jan 1 00:00:00 1970 From: andrey mirtchovski To: 9fans@cse.psu.edu Subject: Re: [9fans] always go for overkill, err vismon In-Reply-To: <017301c3dc24$b2cb30e0$67844051@SOMA> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Fri, 16 Jan 2004 11:56:30 -0700 Topicbox-Message-UUID: bb4d8376-eacc-11e9-9e20-41e7f4b1d025 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