On Sun, 15 Aug 2010 01:19:32 +0800 Brian Wang <brian.wang.0...@gmail.com> said:
> > sure - though it's once thing being a paining program (gimp) and getting a > > bmp load of a totally blank bmp wrong and being a generic library that loads > > images generically for any purpose. gimp can afford to get it wrong without > > much hassle - it's a bigger problem for evas to get it wrong as the intended > > usage is much less clearly defined :) > > OK. That's a sane argument. > Please note that Evas does not load 32-bit BMP with non-opaque pixels > created by GIMP properly. I guess GIMP just creates those based on a > standard with added flavors. By the way, SDL_image loads those just > fine (Evas also beats it on compatibilities too). > > If I ever have time and come up with a patch that does not break 100% > transparent 32-bit BMPs, I'll let the list know. :-) there must be some more correct way - my guess is gimp actually creates bmp's incorrectly (right now) to get an alpha channel in. that's my guess. or someone somewhere broke a standard and everyone has had to cope very since. but there has to be a sane way to do this without having this "all blank bmp becomes not all-blank" problem. > >> > but what i'm more concerned about is.. why are bmp's faster to load? > >> > really? seriously? you've tested? vs what other formats? i really didnt > >> > make any effort to make the bmp loader fast. i just implemented it to > >> > "follow the standards" (that's why u find evas's bmp loader beat gqview > >> > by a large mile as the gtk one is enferior with standards support than > >> > evas's). when i do something i tend to like to do it right. > >> > >> > > >> > now - you'll need to convince me much more that your hack is a valid > >> > patch as it really doesnt follow a standard. what is more of interest to > >> > me is the bmp loading being faster than... something else? what is that > >> > "something else"? > >> > >> I haven't benchmarked BMP vs PNG loading speed with Evas. The 'BMP is > >> faster to load' argument is based on various icon-loading (small 32x32 > >> icons) tests I performed on my prior project (ARM920T device @400MHz), > >> which uses SDL/SDL_Image. I think Evas is smarter with images but I > >> just assume loading/render of raw data (BMP) would be faster than with > >> compressed PNG files. > > > > well that depends. you pay a decompress cost - cpu time, but uncompressed > > (raw) images you pay an IO cost. so which is worse. load 50kb from flash > > and spend cpu time decompressing... or load 200kb from flash and spend no > > cpu time decompressing. also with png you can select your compression level > > and tune things. i suggest you do some actual examining of this with your > > current "target" and try png's with various compression levels. you also > > can use eet to store images (all even in a single file) and then use lossy > > or lossless compression, as well as zero compression (raw argb). so if > > performance is an issue - bmp isnt your only option. other formats give you > > a wider choice. > > On my device and based on my experiments, "raw data I/O" beats > "compressed data I/O + decompression". Of course, it doesn't apply to > all platforms with different I/O performance and computing power. > > Just for the record, I'm not saying BMP offers a _huge_ performance gain. > > I'll try to find time and play with different formats. and thanks for > the eet tip. I'll see if that causes any problem with my icon/UI > artist. :-) it's probably a very good idea to have a little test suite for yourself here. if it really matters to you - have a bunch of formats with a bunch of images that are typical of your usage (small, medium, large, simple, complex etc. content) and then try a range of formats and options within those formats and test time to load :) -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
