Crossfire Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CF: images & caching.

On Mar 8,  3:00pm, Scott MacFiggen wrote:
>
> We are looking at about an 80% decrease in size  on average using
> my conversion program. Other conversion programs won't be as good though
> since they are more general case...
> 
> However I was thinking about something last night. If a client was
> written that used PNG images, it would end up doing a lot of work
> with them.. Basically it would be constantly merging (stacking) images
> to be painted onto the screen.. Since by default PNG images are compressed
> this means uncompressing the image, merging, and writing out a new image
> when is then compressed. Performace is bound to be faster if the
> images are left uncompressed which I believe is legal under the
> PNG spec.

 Yeah - that seems pretty complicated.  Is it possible to write the compressed
version onto disk (local cache), but have a noncompressed version in memory,
and deal with that?  Does png (library I assume) support good manipulations
with in memory data?

 For example, lets take the current case of some grass, a sword, and a player.

 Under current method (xpm), all the images and clipmasks are already in
memory, and in native format (pixmaps).  So the client draws the grass,
sets the clipmask for the sword, draws it on top, then sets the
clipmask for the player and draws it.

 It sounds like you don't really want to convert the png images to native
format until the end, since otherwise you loose some features.

 But is it possible to have the grass, sword, and player png images in
memory?  Then, you make a new png, draw the grass, sword, player using
png functions, and then copy that onto the display.  The temporary composite
image is then tossed away.

> 
> On the flip side there is a big advantage to using compressed images too.
> If we assume the client won't have a local copy of the images
> and the average image size is about 200bytes, it is possible
> to pack about 6 images into one packet and not have that
> packet fragment. Tcp/IP header overhead is like 128bytes right?
> Anyway, being able to send 6 images at a time would speed things
> up a bit..

 Actually, I believe the tcp/ip packet header is around 40 bytes, but
there is then an ethernet header on top of that.  But both of these values
are reduced a bit on ppp connections.

 anyways, fragmentation shouldn't be too big an issue, since an ethernet
packet can got up to around 1500 bytes - if the ethernet packet is full,
the extra 40 bytes for another header isn't that big a deal.

 I am not sure exactly how the OS determines frames, however.  After
all, the outgoing buffer is 64K, so in theory it could maximize frame
size before transmission if enough data is written.  I'll have to look
into how that is dealt with - it might just be worthwhile for the server
to buffer all data for a particular tick, then write it at once to minimize
the number of frams.

> I think it is rather trival to greyscale an image but going all the
> way down to black and white... That is a little different. The PNG format
> however has lots of optional 'chunks' and one of these might be usable
> to store greyscaling and b&w information. Worst case, you can spec out
> a PNG extension for that purpose.  But that means modifying all the
> image tools to recognize the extention and read and write it out
> properly.

 For black and white, it may be worthwhile to just keep the bitmaps then.
At least they should be very easy to parse into native form (whatever
taht may be), and are pretty space efficient.

 Does anyone actually use XPM on black & white systems?  The only advantage
I could see is the extra layers - just curious if anyone finds the extra
layers worth the performance hit.


> What do most people use for XPM editing? Pixmap right? I bet it would
> be trival to modify Pixmap to save files in PNG format too.

 I don't know if it is trivial.  It may not be hard, but there is a big
difference between trivial and not hard.

 Pixmap was largely chosen because it was one of the few things that support
xpm.  But I think that type of editor works pretty good when all you
are dealing with is 24x24 images - many of the more complex features of
other editors can't be used very well on 24x24 images.


-- 

-- Mark Wedel
mark@pyramid.com
[to unsubscribe etc., send mail to crossfire-request@ifi.uio.no]
Follow-Ups: References: