Crossfire Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
CF: images & caching.
The 0.94.0 client does support local image caching. While there is no current
mechanism to preload the cache, it would be pretty easy to write a perl script
that looks through the arch directory and copies files to the cache in the
naming scheme that the client wants.
Image formats: XPM does have the advantage it should be pretty easy for any
system to parse. The XPM library is likely to be more complicated because it
supports reading to a few different image types (ximage vs pixmap), and can
store other values. The XPM form that crossfire uses, while part of standard
XPM, only really uses a subset of XPM features. So all that the client really
needs to care about for XPM parses is the true color names (symbolic and
greyscale names can be ignored), and can also know that there is a 1 byte to
pixel correlation.
XPM is large. However, if that is a big concern, the images could be
precompressed, and the size is typically reduced in half.
As a note - the disadvantage of moving away from GIF is that all existing
images must be converted, and any future work must be done in the same format
or converted to it. This may or may not be easier (if we assume most people
are still working on unix, an editor that supports png/ppm/gif with
transparancy support is then needed, or tools to do the conversion.)
One note about ppm: I don't believe it actually supports transperancies,
although that can probably be synthesized by assign what is current
transpareent to some RGB value in the ppm which is reserved so it is known to
be transparent.
PNG and various transluncy levels: While the image may support it, it will
likely be up to the OS/graphics system if it can do anything useful with them.
I know for a fact that X does not have any real way to draw a translucent
image over another image - these calculations and color adjustments would need
to be done outside of X/via the client. So in that sense, the png form really
doesn't buy anything on that platform - I am not sure if other systems support
it better or not.
JPG: As I recall, it is not very good for XPM, as XPM's are very few colors
and very small to start with - the header information in the JPG file basically
means the file is not any smaller - in fact, I just tried out an image with
XV, and of ppm, jpg, gif, only the gif file was smaller than the original XPM
file.
GIF: Except for the possible patent issues, I think this format would make the
most sense if a switch is made - old enough that tools for most every system
exist, good compression for the type of images crossfire deals with, supports
transparency, and native support in java and web viewers.
--
-- Mark Wedel
mark@pyramid.com
[to unsubscribe etc., send mail to crossfire-request@ifi.uio.no]
Follow-Ups: