On Sun, 15 Jul 2007 14:54:38 -0600 "Eric Wasylishen" <[EMAIL PROTECTED]> babbled:
> Hi, I have a few questions related image loading. > > One thing I'm working on is an xmms2 client using ETK/evolve. I'd like > it to show album cover art; the way the xmms2 client lib handles this > is it gives you a pointer to an image file that was copied in to > memory but not decoded. People using gtk have a function in gdk_pixbuf > for this, which automatically determines the image format (probably > jpg or png for covers) and decodes it, but as far as I can tell > imlib2/evas lack this feature? (though I noticed epeg can load a jpeg > file from memory.) correct. no such feature. > One option I though of is just copying the loader code for say JPG and > PNG from evas or imlib2 in to my app, and modifying it to do what I > need. Or, would loading images from memory be useful enough to go in > evas or imlib2? well personally i put imlib2 on "life support". i don't want to put things into it. if it goes anywhere - it's evas. as for being useful - definitely. but to date it has not been a hard requirement. > Another project I'd like to do is an image viewer where image loading > doesn't block the GUI. After some reading my plan is to write a daemon > which loads the image data in to shared memory for the gui app to > access, though I'm not sure what advantages/disadvantages this would > have over doing it in a thread. > To get the best performance possible, I want it to load jpg's at a > reduced size (epeg and evas can) and be able to cancel loading an > image (only imlib2 can?) So far the best solution I can see is to use > epeg and imlib2. Any better ideas? > > I greatly appreciate any tips or advice.. thanks :) ok - this goes into a whole new world. as discussed before - evas is getting to the stage where it may need threads/ipc connections etc. of its own (to talk to shared image cache daemons, etc.) and we may need to export an FD from evas - much like xlib and xcb export fd's and allow ecore to listen on them waiting for events. why talk about this? this allows us to now have something like evas_object_image_load_policy_set(obj, EVAS_LOAD_POLICY_ASYNC); and that will hit to evas to load image data in the background - that means either a thread or daemon does this and writes back to evas via a file descriptor as progress happens. this can allow the load to go on in the background. existing loaders will need to be modified to support this, but it is possible. then when evas's fd becomes active you call evas_process(evas); to read any data on the fd (events) and process anything - then: evas_render(evas); to render any updates - if there are any. this would give you your progressive loading, non-blocking, and make it available to anyone. a first SIMPLE implementation could be to just load the whole image in the bg in a thread that is spawned IF the image is set for async load policy - and when it is 100% done, write and event back to evas. you won't see the decode as it loads, but you won't block - it will be blank, then suddenly appear. later loaders can be made smarter to send events as they decode (registering which sections of the image decoded). as for loading from memory - i see no reason we cant have a evas_object_image_memory_set(obj, pointer_to_data, size_of_data); (and a get too). this will match with evas_object_image_file_set() and get. again - loaders will need to be adjusted to handle this, and not all loaders could necessarily do it (depending on the back-end decoder lib being used). evas can't do a quick-guess on extension as to what loader to try first, so it will need to use a brute-force try and use all loaders until one succeeds. > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
