In fact, the image data is generated on the fly(I'm writing an procedural image generator). Internally, they are stored as SIMD floating point vectors, with 4 elements, rgbx, where x is an undefined value and each ranged from 0 to 1. I chose PPM because the file format is SIMPLE.
Can I disable async preload of elm_image? Must I touch the lower level thing? Anyway, I'll learn more about the low-level stuff. The lack of documents really sucks. BTW, here is what I'm writing: http://cjprods.org/ipu/ , licensed under The MIT License. >On Fri, 22 Feb 2013 16:03:57 +0800 (CST) 哆啦比猫 <cj...@126.com> said: > >> What I want to do is: >> >> >> // show result in Image Stack (a table, in fact) >> elm_table_clear(stack, true); >> for (int i=ipu_stack_length()-1; i>=0; i--) { >> image = elm_image_add(win); >> elm_image_resizable_set(image, 0, 0); >> evas_object_size_hint_min_set(image, 256, 256); // all the images are 256x256 >> evas_object_size_hint_padding_set(image, 10, 10, 10, 0); > >dont set min size (and padding may or may not be used/honored by widgets. they >all pretty much only honor min/max size. anything else is optional). if you >want direct control like this - drop down a layer to evas image objects. don't >use elm image objects. elm objects set min/max size hints for you and will just >fight with you on the sizing. > >> ppm = ipu_ppm_get(&ppm_size); // get the image from top of ipu's stack, in >> PPM format elm_image_memfile_set(image, ppm, ppm_size, "ppm", NULL); >> ipu_ppm_free(ppm); > >just so you know... loading images from memory is less efficient than from >files on disk. ALSO be aware since you are using a ppm... its in memory >UNCOMPRESSED as RGB data... that's about as inefficient as u'd get... you are >BETTER off having it as a jpeg maybe or a png even... in memory - and even >better off having it separate on disk. if you must have the data compiled into >your executable... convert to ARGB premultiplied format (32bits - 1 int per >pixel) and then just have into on width, height and alpha mask and then set the >argb pointer directly on the image... to do that you will have to drop down to >evas image objects. like this: > >int mydata[] = { > 0x00000000, 0x88888888, > 0xffff0000, 0xffffffff >}; >int mywidth = 2; >int myheight = 2; >Eina_Bool myalpha = EINA_TRUE; > >Evas_Object *img; > >img = evas_object_image_filled_add(evas_object_evas_get(win)); >evas_object_image_size_set(img, mywidth, myheight); >evas_object_image_alpha_set(img myalpha); >evas_object_image_data_set(img, mydata); > >... convert your image into some c data array declaration as above. this will >save memory (the data will be used directly from your executable and not >duplicated if possible). it just isnt compressed, so disk-space will be ugly if >these images get big and plentiful in your code. in the end as i said - i >advise putting them into actual data files. there are ways to pack them all >into a single resource file (eet for example - this is actually what edje files >are). > >> elm_table_pack(stack, image, 0, i, 1, 1); >> evas_object_show(image); >> >> ipu_ignore(); // pop the top of ipu's stack >> } >> >> But the table "flashes", then show the images. I don't want the "flash" when >> reset the content of the table. I've tried elm_win_norender_push() and >> elm_win_norender_pop(), but seems not working as expected. I've also tried >> creating a new table, then set it to the content of it's container, not work >> neither. > >it flashes because elm_image automatically enables the async preload feature of >evas - it means evas only synchronously checks the image header and doesn't >decode the data immediately. it decodes it in a background thread and THEN when >its decoded, elm_image will show the image. until then its hiddden. this avoids >blocking and waiting, but means that you get this behaviour. higher level >widgets do this - they layer on top extra behaviour. it is often handy/useful, >but in your case probably isn't what you want, so drop down to a more manual >layer if that's what you want. > >n.b. you can create your own composite objects via smart objects. this lets you >create intelligent objects with exactly the kind of behaviour you desire. >terminology does this with "media" objects. it uses this to do smart stuff like >turn smooth scaling and and off while the object keeps resizing (to make zoom >animations smoother), and then when it stops for a little while it turns smooth >scaling on again. the same trick is used to deal with vector data files >(ps/pdf/svg) by re-loading the image when resizing stops but telling it to >render at the "current pixel size" and thus have perfect correct scaled data, >but having fast bitmap stretching in between. > >> -- >> Where there is a hacker, there is art. >> ------------------------------------------------------------------------------ >> Everyone hates slow websites. So do we. >> Make your web apps faster with AppDynamics >> Download AppDynamics Lite for free today: >> http://p.sf.net/sfu/appdyn_d2d_feb >> _______________________________________________ >> 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) ras...@rasterman.com > ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
