Re: [gtk-list] Imlib 1.9.0 question

[raster redhat com]

On 20 Jan, Andreas Tille scribbled:
->  Hello,
->  
->  if this is not the right place to ask Imlib question please tell
->  me where to ask.  I didn't found any other place.
->  
->  1. Tracing the Imlib 1.9.0 sources I detected a change in loading/saving
->     image files.  Up to 1.8.2 a hhard function was called.  Now there
->     is a pointer to a function which is called to load the image.
->  
->     I suppose that the sense behind it is to geve the user the chance
->     to define its own loading/saving routines to read/write special
->     chunks in PNG or tags in TIFF, etc.
->  
->     But there isn't any documentation how to tell Imlib about the
->     user defined function.  Could someone explain me how it works?
->  
->     It is from great interest for me, because I recently use a modified
->     Imlib loading routine to read special chunks/tags and would like
->     to go a clean way.

these changes are not 100% finalised - 1.9.2 is imminent - ned to clean
this up - notice all the loaders are now .so's - but there isn't a
"pluggable" api to them - i don't expect a program por user-level
plugin system till 2.0 - this changed merely to save memory.

->  
->  2. At present time it is not possible to use Imlib without X or
->     GDK initialized.  I would like to have a chance to use the Imlib
->     functionality off line (the way convert of ImageMagick does).
->     That's the second reason why I did my own loading routine.
->     I would like the way that loading/saving and some image
->     manipulation functions could work without initialized display.
->     This could cause only problems with XPMs but this could be easily
->     avoided.
->  
->     The initialisation of the display has to be done before rendering
->     the images as pixmaps of course. 

Imlib 2.0's design currently has all the code delayed - ie all init's
and loads are delayed till the last possible second (for example - whne
loading images it gives you an opaque (now opaque) handle but only
loads the image header, if the plugin allows this, so it just detects
width, height, image format and depth etc.. but does nto decode the
image data - the image data is decoded in a second pass just before the
data is actually needed by rendering or exporting of the data). the
same can be done for display initialisation.

->  3. Since I used Imlib 1.8.2 I've got SIGSEGVs ofter manipulating the
->     rgb_data of an imlib structure.  For instance I used my own
->     routine to mirror images.  Switching from 1.8.1 to 1.8.2 lead to
->     SIGSEGVs in this routine.  Using Imlibs own routine helped to avoid
->     the SIGSEGVs but I have to do certain image manipulation on the RGB
->     data which can't be done with Imlib functions.

did you change the rgb_data pointer? if you did you most certainly will
have done some nasties - yes i know - it  should be opaque. i'm fixing
all this in 2.0

->     Was there any change in the internal Imlib structure???

you may chang the datat rgb_data points to but not the pointer... :)

-- 
--------------- Codito, ergo sum - "I code, therefore I am" --------------------
raster@rasterman.com       /\___ /\ ___/||\___ ____/|/\___  raster@redhat.com
Carsten Haitzler           | _ //__\\ __||_ __\\ ___|| _ /  Red Hat Advanced
218/21 Conner Drive        || // __ \\_ \ | |   \ _/_|| /   Development Labs
Chapel Hill NC 27514 USA   ||\\\/  \//__/ |_|   /___/||\\   919 547 0012 ext 282
+1 (919) 929 9443, 801 4392   For pure Enlightenment   http://www.rasterman.com/

              \|/ ____ \|/  For those of you unaware. This face here is in fact
	      "@'/ ,. \@"   a Linux Kernel Error Message.
	      /_| \__/ |_\
		 \__U_/