On Sat, 31 Aug 2002, Tomasz wrote:
> Could you possibly give me a hint how to relatively quickly
> and straightforwardly
> deal with images in ggi-library?
I had to deal with this recently in creating driftview, a viewer for
driftnet feeds based on GGI. There are several options I considered:
1) Use an image loading library like ImageMagick to load the image into
a display-memory visual of the correct color-depth, then cross-blit the
image from the memory visual to the main visual. The advantages and
disadvantages of thas are as follows:
a) Disadvantage: Generic image loading libraries have lots of
dependencies on other libraries. It is not so bad if they
have dependencies on libjpeg and such, but in the particular
case of ImageMagick the library was written originally as an
XLib image reader and even though they have hacked things so
that you can use it without an X server, there is still a
dependency on Xlib.
b) Advantage: maintainance of the image loaders and fixing of bugs
and security problems are done by the maintainers of the
image reading library. Packaging for distributions is handled
by distro package maintainers.
c) Disadvantage: This greatly increases the memory profile of
your application, and depending on which image formats you
want to use, may and up being very inefficient.
2) Rip the source code for the image formats which you want to support
from an image viewer program or image loader library, and do essentially
the same thing as 1). This entails some coding to extract the image
loader from the library or viewer (bypassing or providing global variables
and common functions). This gets rid of a) but you do not benefit so
much from b).
3) Rip the source code for the image formats which you want to support
as in 2) and write an incremental loader that uses shallow Get/Put GGI
buffers. This will be more coding but will reduce the app's memory
profile and increase efficiency.
4) Learn and use LibGPF, which has image loading as one of it's objectives.
However, LibGPF is pretty new and you'll end up having to code most of
the actual meat yourself at this point -- but of course that will add
to LibGPF so the next person in your situation will benefit also from
your work. That and though LibGPF's external API is stabilizing there
are likely to still be changing, and the internal intrafacing is still
pretty much in flux, so it will be a moving target.
Things would be much simpler if a nice incremental, low profile, image
loading API like the one used in libpng were written for all the different
image formats. Libgif's API is not too bad either (libpng is obviously
based on libgif) but using libgif results in potential patent issues.
If you are in control of the specific image formats you are going to
use, I would restrict the image format to single-frame PNG images of
a specified bit-depth, and use 2) or 3) with libpng. I haven't completed
the PNG loading for drifview yet but that's simply due to laziness
on my part (it's a little more difficult because I have to handle all
types of PNG images so bit-depth conversion is necessary.)
--
Brian
