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

Re: CF: win32 client and XPM

Brian Thomas (thomas@astro.psu.edu) wrote:

> 	I too more or less agree with this. THe format of the 
> 	images sent from the server should be in the simplest,
> 	*least bandwidth* impacting format. We should highly prize
> 	performance over ease of implementation (server side).

I don't quite agree with that (but then, my name is not in the cf hall
of fame :-)). Performance is _no_ issue at all, since
a) server-side: you only need to send image data. No need to "understand"
   what your are sending, so it can be any complexity
b) bandwidth: who cares? Implement a working image caching scheme --- this
   saves more bandwidth than any compression scheme. Since images need
   only be transmitted once, it doesn't really matter what format
   they are in. People could also download the images beforehand, in
   whatever format their client likes them (could be compressed XPM, PNG,
   GIF or YYTRTEYIUQETYR).
c) client: because of the image caching, conversion need only be done
   when a _new_ image is received from the server. After that, the
   converted image is cached, and need never be converted again.

_My_ conclusion is that the emphasis should be to ease c). That is,
images received from the server should be in an extremely simple
format, so clients can create a "bitmap" with "less than a screenfull"
of code, and dump that bitmap onto their local disk in their native
image format. Or they could create a large image. Doesn't really matter,
since that's a decision to be made by the client designer.

I'm not even sure that I like compressed XPM images to be sent by the
server, since that already complicates things. Instead, people should
download the set of standard images "precreated" for their client,
or they client might even come with the complete set of _standard_
images. New images, special images used by a server (or map, if the "put
images into maps" gets done) would be added automatically via the
image caching mechanism; but there will only be _very_few_ images,
so compression probably makes things complicated without adding any
benefit.

Just my $0.02,
   Christian


-- 
Christian (Icho/Gandhi/Ribald @sunbroy53.informatik.tu-muenchen.de, 13326)
[to unsubscribe etc., send mail to crossfire-request@ifi.uio.no]
Follow-Ups: References: