On Sat, Aug 14, 2010 at 9:11 PM, Carsten Haitzler <ras...@rasterman.com> wrote: > On Sat, 14 Aug 2010 21:06:33 +0800 Brian Wang <brian.wang.0...@gmail.com> > said: > >> On Sat, Aug 14, 2010 at 6:24 PM, Carsten Haitzler <ras...@rasterman.com> >> wrote: >> > On Wed, 11 Aug 2010 10:27:58 +0800 Brian Wang <brian.wang.0...@gmail.com> >> > said: >> > >> >> Hello raster, >> >> >> >> I stole some time and made an app for showing bitmaps in bmpsuite.zip. >> >> Please see the PNG screenshot disguised in txt as attached. All >> >> bitmaps are shown (properly, i think). gqview seems a bit weaker than >> >> evas. :-) >> >> >> >> And yes, 32-bit bmp is a format i care a lot of since the loading is a >> >> lot faster. :-) On a platform with weak computing power, i have to >> >> save bits and pieces here and there. >> >> If there's no problem, please check my patch and correct it when you see >> >> fit. >> > >> > hmm well the text file attached corrupted - cant see it. but... i also >> > created a mini image viewer too for this purpose. as such your patch will >> > break transparent bmp's (100%) which is really an incorrect thing. if you >> > can find a way to make it not incorrect - no problems. i really don't like >> > the fix because of its nature. >> >> Well, that's what GIMP does. I guess it's a workaround and it'll be >> 99.99% accurate since 100% transparent BMPs aren't exactly popular. >> 32-bit BMPs aren't popular either. If my patch is not ok for the >> upstream, I'll just keep it private. I'm perfectly ok with it. > > 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. :-) > >> > 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. :-) BR, brian > > -- > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > The Rasterman (Carsten Haitzler) ras...@rasterman.com > > -- brian ------------------ Cool-Karaoke - The smallest recording studio, in your palm, open-sourced http://cool-idea.com.tw/ iMaGiNaTiOn iS mOrE iMpOrTaNt tHaN kNoWlEdGe ------------------------------------------------------------------------------ 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
