[Freeciv-Dev] Re: imlib version 2

[raster@xxxxxxxxxxxxx]

On 21 Jun, Vasco Alexandre Da Silva Costa scribbled:
->  On Tue, 20 Jun 2000 raster@xxxxxxxxxxxxx wrote:
->  > On 20 Jun, Daniel Burrows scribbled:
->  > ->  On Tue, Jun 20, 2000 at 04:27:48PM -0600, Roger Tucker 
<roger.tucker@xxxxxxxx> was heard to say:
->  > ->  > I wonder if anyone has thought about when Freeciv should
->  > ->  > be updated to use Imlib2 over Imlib.
->  > ->  
->  > ->    IMO, if we're going to throw imlib out we might as well use 
gdk-pixbuf.
->  > ->  I haven't contributed a line of code for months, though, so you know 
what
->  > ->  my opinion is worth :-)
->  > 
->  > you could.. then again you could get a considerably faster renderer
->  > with imlib2 - i've done performance tests and it beats gdk-rgb by about
->  > 5-10% and gdk-pixbuf form double the speed and up :)
->  > 
->  > i'm workign on getting hardware acceleration into imlib2 right now
->  > actualy.. it will take a little while.. but i'm personally banking on
->  > hardware accel - so it WILL happen :)
->  
->  First off, i'm sorry if this answer will be spamming you raster, i guess
->  you probably have to read enough email :)
->  
->  As far as gdk-pixbuf, imlib, imlib2 issues go:
->  
->  1) Is gdk-pixbuf still requiring imlib?  i think it did some time ago.
->     If it isn't, it still requires libart, not everyone has it installed.
->      (yes i know GNOME comes with libart but gtk+ doesn't)

no - gdk-pixbuf doesnt.

->  2) Imlib has it's fair share of problems.  However we are using it now.
->     One good thing is it doesn't require libz, libpng, etc to be installed
->     unless you really require those plugins (probably gdk-pixbuf does the
->     same?)
->  
->  (In my view we should use GdkRGB or do colour quantization/dittering 
->  ourselves, that would allow to use better the Xaw client on displays with
->  a low colour resolution, yes we could use Imlib for X, but the Xaw players
->  are usually hardy folks which don't like to install extra libs on their
->  system :), besides it would introduce an extra dependency in the code).
->  
->  3) Imlib2, i don't know much about it to comment, except it probably
->     doesn't come preinstalled/with the standard distributions in any
->     systems at all (at least yet) so it isn't an option IMHO (maybe
->     Mandrake?).

yup- it's fairly new - i'm aiming it to be a fast 2 D compositing
(immediate mode) engine with ability to load/save to disk too. it does
all that alreayd - and does it faster than most stuff - in software
(since its mmx optimized the mmx code is fast - even the C versions fo
the rotuiens are faster than anything i've hit sofar)

->  PNG loading support would probably be useful, but that requires libz and
->  libpng and several people have already complained because of that too).
->  
->  We will probably have to end up using our own loader, PNG or TGA IMO.
->  (Don't feel shocked, most games on any platform do things this way).
->  
->  
->  Oh yes, we only use imlib for pixmap loading & colour quantization/dittering
->  right now, in case you are thinking what are the changes involved, and
->  that code is fairly contained.

imlib2 does all of this - and probably how you'd want it - the
loader/saver's are models - they are .so's dlopen()'d by imlib2 -
imlib2's dist may build them but you dont need any of them for imlib2
to work - it wont be able to load or save images - but it will work.

it also does the renderng - same as gdkrgb - BUT it does it faster for
the cases i've managed to test. it does dithering in 16bpp and below (if
you want) - can do all the image rendeirng you want (sprite compositing
WITH alpha blending etc.) and will have a lot of the backend
accelerated in hardware - as soon as i can make opengl behave itself
and not segfault my Xserver :)

it's up to you. just thought i'd keep the facts out there for you to
figure it out. :)

-- 
--------------- Codito, ergo sum - "I code, therefore I am" --------------------
The Rasterman (Carsten Haitzler)    raster@xxxxxxxxxxxxx     raster@xxxxxxxxxxx
                                    raster@xxxxxxxxxxxxxxxxx raster@xxxxxxxxx
                                    raster@xxxxxxxxxx