On Mon, 6 Mar 2006 19:11:31 +0100 Martin Hauser <[EMAIL PROTECTED]> babbled:
> Hello, > > > On Mon, 6 Mar 2006 10:41:37 +0100 Martin Hauser <[EMAIL PROTECTED]> > > babbled: > > > > > Hello, > > > > > > I've just downloaded a huge image from the spaceteleskope homepage > > > and tried to view it in exhibit. The result was the following: > > > > > > [EMAIL PROTECTED]:/home/mh% identify heic0602a.jpg > > > heic0602a.jpg JPEG 15852x12392 DirectClass 62.1mb 24.060u 1:21 > > > > > > [EMAIL PROTECTED]:/home/mh% exhibit heic0602a.jpg > > > zsh: segmentation fault exhibit heic0602a.jpg > > > > > > You see the sizes listed above using the 'identify' tool from > > > imagemagick. > > > > u do realise that image will consume 750MB of ram? its quite likely > > that an alloc is failing somewhere that isn't been caught and > > propagated safely. a backtrace would be nice. :) > > > > uuups, no i did not realize, but in any way, it shouldn't be really > segfaulting i believe. Check the available mem and prevent the opening > of the file or such, but segfault, i doubt is a good thing. you can't just "check the available ram" - that's not really sane/feasible. it could be the OS overallocating - some OS's do that (malloc succeeds even if u dont have enough ram+swap hoping you dont actually write to/use all of it). > > > Steps to reproduce it: > > > > > > 1. Start exhibit with the named image from the command line. > > > The display of the image is broken, you just see black with > > > strange stripes, but not the actual image. > > > > it managed to get that far? it should have just failed at load time! > > > > Yeah, that's what i would have expected. Some popup like : "This image > is too large to be loaded into ram" in reality - the malloc() to allocate the pixels (750MB worth of ram just for that image) should probably have failed - and thus the image load failed etc. etc. > > > 2. Start scrolling around, after a few seconds exhibit will > > > segfault. > > > > > > gdb backtrace: > > > > > > (gdb) run heic0602a.jpg > > > Starting program: /usr/bin/exhibit heic0602a.jpg > > > Etk Warning: etk_image.c, 608: _etk_image_load: Unable to load image > > > from edje file > > > "/usr//share/etk/icons/default.edj"/"actions/help-contents_16", > > > error 8 > > > > no gdb debugging symbols - this doesnt help a lot. somewhat, but not > > a lot :( > > > > You do need such a backtrace? i could recompile stuff with debugging > symbols and try if need would be, though i'm not completely sure if i > know off the shelf how to do that. (i know about -g and stuff, but i > have no idea how to get this into the efl automake stuff). But i > remember there was a link on get-e.org (remembering now) how to get the > stuff running, will have a look at that if need be. export CFLAGS="-g" make clean distclean ./configure make make install (for example) - i suggest you do this anyway.but i have the image downloaded sou can check myself. > > > Program received signal SIGSEGV, Segmentation fault. > > > 0xb7c0ed03 in evas_common_copy_pixels_rgba_to_rgba_sse () > > > from /usr//lib/libevas.so.1 (gdb) bt > > > #0 0xb7c0ed03 in evas_common_copy_pixels_rgba_to_rgba_sse () > > > from /usr//lib/libevas.so.1 #1 0xb7c23d45 in > > > evas_common_scale_rgba_in_to_out_clip_smooth_mmx () > > > from /usr//lib/libevas.so.1 #2 0xb7c2bf1f in > > > evas_common_scale_rgba_in_to_out_clip_smooth () > > > from /usr//lib/libevas.so.1 #3 0xb7e3f74d in ?? () > > > from > > > /usr//lib/evas/modules/engines/software_generic/linux-gnu-i486/module.so > > > #4 0x081b3f10 in ?? () > > > #5 0x080ef778 in ?? () > > > #6 0x08074e20 in ?? () > > > #7 0x00000000 in ?? () > > > > > > here's the image that broke exhibit: > > > > > > http://www.spacetelescope.org/images/large/heic0602a.jpg > > > > ok... the image! cool. time to kill things. BTW - chances of that > > image ever loading and displaying are pretty close to zero - as it > > will need more ram in one big block than most systems can manage :( > > > > Yeah, i wonder myself why the guys at the site are providing it, i just > had to have a look at it as it's the bigest image i have every gotten > my hands on (damn, the .tif file has 445 MB, the .jpg 62 mb) But i was > aware that it won't really ever display good. oh - it is possible to display it if you have SHITTONNES of ram - the way evas stores things as ARGB it needs 750MB. if you stored just RGB it would be 563MB (as it has no alpha) - but when this kind of stuff really matters you wqant to start SPECIALLY treating such huge images when loading and load them in tiles (divide the image up into lets say 1000x1000 sections and load just the ones you need as you need them - this means having to open and re-load the image many times, and only decode the sections you want, but it does then work.) - but the main point is - at this extreme end of the spectrum for images, you need SPECIAL techniques to deal with them and evas does not employ any of them. it uses the simple generic way of "load it all into ram and then use it" way for speed and simplicity. > If you need anythin else, let me know > > Martin > -- > Martin Hauser <[EMAIL PROTECTED]> > GPG-Encrypted mail preferred, KEY: 0D459A72 > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ enlightenment-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-users
