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 :) > > 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. -- ------------- 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
