*BSD News Article 25744


Return to BSD News archive

Xref: sserve comp.os.386bsd.apps:834 comp.windows.x.i386unix:6350
Path: sserve!newshost.anu.edu.au!munnari.oz.au!bunyip.cc.uq.oz.au!harbinger.cc.monash.edu.au!aggedor.rmit.EDU.AU!goanna.cs.rmit.oz.au!numbat!s902150
From: s902150@numbat.cs.rmit.OZ.AU (Brian Havard)
Newsgroups: comp.os.386bsd.apps,comp.windows.x.i386unix
Subject: Re: Problems with xv-3.00a and a question.
Date: 8 Jan 94 13:48:34 GMT
Organization: Comp Sci, RMIT, Melbourne, Australia
Lines: 39
Distribution: world
Message-ID: <s902150.758036914@numbat>
References: <CJ3M5r.Cvp@news.direct.net> <s902150.757870494@numbat> 	<1994Jan7.022121.29531@sserve.cc.adfa.oz.au> <PCG.94Jan7212114@decb.aber.ac.uk>
NNTP-Posting-Host: numbat.cs.rmit.oz.au

pcg@aber.ac.uk (Piercarlo Grandi) writes:

>>>> On Fri, 7 Jan 1994 02:21:21 GMT, wkt@cserve.cs.adfa.oz.au (Warren
>>>> Toomey) said:

>Warren> In article <s902150.757870494@numbat>,
>Warren> s902150@numbat.cs.rmit.OZ.AU (Brian Havard) writes:

>Brian> I've also come across this problem but I found that if you leave
>Brian> it going for long enough (a couple of minutes usually) it _does_
>Brian> come up.  I'm using a 386-40 8 megs. Top shows it using all free
>Brian> CPU time the whole time. Once it does come up, however, I found
>Brian> it failed to set the palette correctly and was exruciatingly
>Brian> (spel?) slow to do anything.
> 
>Warren> I've had the same problem. Earlier versions of xv were fast to
>Warren> start and fast to use.

>The main difference between xv 2 and xv 3 is that xv 3 does support 24
>bit color images, _even on an 8 bit server_. This means that if you open
>a JPEG (or any?) file it will be expanded in memory to a full 24 bit
>color image, and _then_ a copy of it will be made for display in 8 bit
>mode. The 24 bit original is retained because any work you do on the
>image is done on it, not on the 8 bit copy used just for displaying an
>approximation.

>If you huge memory problems with xv 3 are due to trying to display 24
>bit images, the following are possible solutions:

  Who mentioned JPEGs? It takes ages just to start before it event gets
a look at an image file. Also, memory isn't a problem as I was able to
load up and display a JPEG with NO swapping occuring. It just takes 
forever. Seems to me that it must be using floating point alot and a
386 without co-pro makes it crawl.
-- 
_______________________________________________________________________________
|  Brian Havard                 |  "He is not the messiah!                    |
|  s902150@minyos.xx.rmit.oz.au |  He's a very naughty boy!" - Life of Brian  |
-------------------------------------------------------------------------------