Re: [gtk-list] Re: pixmap loading slowness

[raster redhat com]

On  7 Feb, Owen Taylor shouted:
->  
->  ALT2376@ritvax.isc.rit.edu writes:
->  
->  > 	has anyone noticed that gdk_create_pixmap_from_xpm_d() is very slow?.
->  > Its like 10 times slower than gdk_create_pixmap_from_xpm(). Gimp doesnt even
->  > use this routine to embed pixmap. Does anyone else have an alternative
->  > way(shorter) other than what gimp does?. 
->  
->  If you told me that gdk_create_pixmap_from_xpm() was slow, I wouldn't
->  be suprised (that's a known problem). But I'm suprised that 
->  gdk_create_pixmap_from_xpm_d() is any slower - it appears to be
->  simply the code in the former with the file operations taken out.
->  
->  I have some patches sitting around that I wrote but never tested,
->  that should help from_xpm() - they change a lot of fscanf(...,"%c"...)
->  to getc() - more than 10x faster. But if _xpm_d() is equally slow,
->  than there isn't much point in putting them in.

I wrote my own XPM loading routine - about 250 lines of code total. It
should be pretty fast - but then again I can't say how slow it is... its
about the same speed as loading gif's or png's or any other format - I
can't tell on my PII-300 - I need people to test this. :)

->  The problem with the gdk_create_pixmap... functions is actually
->  pretty obvious. They use XPutPixel for _each_ pixel in the image!
->  (talk about lots of server traffic). It wouldn't be that hard

actually... XPutPixel doesn't cause any server traffic - it is a local
macro generated for the current XImage (which is client side) - only
XPutImage and XGetImage will generate any server traffic :) Oh - and
its not too much slower than byte-bashing. Check the XImage structure -
there are pointers to the XPutPixel and a XGetPixel functions there -
the main overhead is the function calling (ie putting registers on
stack, jsr (jump subroutine) etc. and then the return) - this does slow
it a bit compared to "byte bashing". Imlib has the option of doing both
(fastrender does byte-bashing - gives you about a 15% speedup depending
on depth). Also does the GDK routines use shared XImages? If not this
could be also rather slow.

->  to write something better (using code from GdkPreview)
->  but it feels a lot like re-creating the wheel.

Well I already have the "something better" - encapsulated in a whole
library - you can use Imlib as is currently - and when this is out it
will also inherit transparency for PNG, GIF, TIFF and XPM files.

->  Right now I'm thinking it might be best just to go back to using
->  libXpm - though it would be good to investigate just why we
->  switched from it in the first place. I think there might have
->  been problems with broken versions of libXpm... Also, there would
->  be problems with libXpm allocating colors outside of GDK's 
->  control
->  
->  As for your immediate problem, if you're willing to link with
->  libXpm, and you're desperate you could try the following:
->  
->  It's code from the original gdk_create_pixmap, modified to
->  do special things for gsumi (substitute colors), and re-modified
->  not to do that. (I haven't tried out the code after that last step...)
->  
->  You could also look at using gdk_imlib, though I'm not sure
->  that can deal with embedded data.

Yup - it can. 

GdkImlibImage *gdk_imlib_create_image_from_data(unsigned char *data, unsigned char *alpha, gint w, gint h);
the difference is it's not an XPM inlined - it's raw 24-bit data
inlined (RGBRGBRGBRGB) - better quality for large images. it sould be
blazingly fast (well the whole creating of an Image is jus a memcpy)

->  Regards,
->                                          Owen


-- 
--------------- 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 Enlightenmenthttp://www.rasterman.com/