On Fri, 13 Nov 2009 11:27:57 +0800 Brian Wang <brian.wang.0...@gmail.com> said:
> On Fri, Nov 13, 2009 at 11:14 AM, Carsten Haitzler <ras...@rasterman.com> > wrote: > > On Fri, 13 Nov 2009 10:47:41 +0800 Brian Wang <brian.wang.0...@gmail.com> > > said: > > > >> On Fri, Nov 13, 2009 at 8:59 AM, Carsten Haitzler <ras...@rasterman.com> > >> wrote: > >> > On Thu, 12 Nov 2009 12:07:17 +0800 Brian Wang <brian.wang.0...@gmail.com> > >> > said: > >> > > >> >> [ snip ] > >> >> > I really want to know screenshots of it. Really, Raster would know the > >> >> > lack of dithering and blockier gradients because he has "eagle's > >> >> > eyes", but generally you see minor glitches most people will not > >> >> > notice. The biggest one so far is blending white on white, but I even > >> >> > worked it around and it should handle this special case (giving you > >> >> > white instead of green-ish gray). > >> > > >> > "use the 32bit software engine" is my advice. yes. it is slower. but the > >> > quality is higher and it is complete. the things you see in these shots > >> > are: > >> > > >> > 1. 16bpp engine does no smooth scaling. so scaling is nearest picking of > >> > pixels always. if smooth is set on or off. > >> > 2. the font garbage is the 16bpp enigne not handling bitmap fonts. the > >> > 32bpp engine does, if the font has a bitmap for a glyph. > >> > 3. imges are converted to 16bpp (from 32) on load with dithering. thus > >> > the odd colors and "boxy speckles". > >> > >> Both worlds are good! I will make 'static' applications run with > >> 32bpp engine and 'moving' apps run with 16bpp (lists apps). It's hard > >> to ditch either of them. > > > > well - me. i would ditch the 16bpp one. but.. as long as you know the 16bpp > > one will have caveats and bugs.. then fine. you can work around them. or > > help fix them. if you want it working properly - the software (32bit) > > engines are the go. remember we also have a GL engine. if your devices SoC > > has a built-in 3D unit that can do GL-ES2.0 or better (well ok nothing > > better at this stage) then evas gl engine will also work. you will need. > > the same gl engine that works on desktop also works on GL-ES. > > > > 1. working gl-es drivers/libs from your vendor that support X11 - i know the > > TI SXG drivers for the omap3 series (and up) do. > > 2. --enable gl in evas's built and enable gl in ecore-evas. then it will > > "just work". you will need env vars for elementary to select engine: export > > ELM_ENGINE="gl" will do the trick. > > 3. you'll of course need a target soc with 3d and the drivers. > > > > if you cant do the above - you'll be stuck in software rendering land as you > > are now. that's not bad. just remember you have options. you can try gl on > > your desktop too. > > I'm stuck in software rendering... There is only a 2D accelerator HW > in the SoC but I don't know how/where to put it and it is of any good > use with evas... to use it you'd need to have a way for evas to access it - in reality the best u might manage is blit acceleration for copies to the screen. that's about it. you could try xrender engine and accelerate all of x and xrender, but i dont think you'll win over software there. you'd have needed to do all the x driver work anyway to get that far. i've lost interest in the xrender engine. i'm tired of never seeing any decent acceleration for it. i want to lean down to 2 core engines. software 32bit ones - they only differ in the buffer output mechanism. eg fb vs x11 vs win-ce etc. and gl. i'm giving up on all other engines. that includes the 16bit one > >> > things you haven't seen yet... > >> > > >> > 16bpp engine doesn't do maps. eg this: > >> > http://www.youtube.com/watch?v=6tuVSkrdjiE > >> > http://www.youtube.com/watch?v=edLTo61dIgA > >> > > >> > (it's new, but i am not going to add it to the 16bpp engine. only generic > >> > 32bit software and gl. gl is half done atm). > >> > >> Wow. Is it usable on a 400MHz ARM926ejs performance-wise? > > > > dunno. but its not too bad on my arm11 (armv6 - s3c6410) @ 532mhz rendering > > on a 800x480 display. so if you are in qvga land it might be ok too on an > > arm9 and you dont have horrible display bandwidth issues. use it wisely. it > > can be costly. also note there is a smooth and non-smooth mode for the maps > > so turning it off gets u between 2-4x speedup or so. smooth is there for > > quality reasons. it's the default. > > Is the code in svn? I'll play with it a bit in my spare time. all the rendering/evas code is. the elementary demo isn't - its a small test app here that i modified from work by gustavo to add more child widgets for testing. expedite test is also in svn btw. u can check it out and play. it's our "see how fast your target" is tester (as well as testing improvements in evas). i'd suggest giving it a run on your target and positing your results so you can compare. know where yu stand in performance relative to your desktop and thus know what you can achieve. > >> > you can't use argb image for rendering data. last i checked yuv video > >> > wasnrt handled. the 16bit engine is a subset of evas's rendering > >> > abilities with a drop in quality in a tradeoff for speed. > >> > > >> >> These are all captured on my x86 box: > >> >> > >> >> Home screen: > >> >> http://cool-idea.com.tw/brian/x11-home.png > >> >> http://cool-idea.com.tw/brian/x16-home.png > >> >> > >> >> Music: > >> >> http://cool-idea.com.tw/brian/x11-music.png > >> >> http://cool-idea.com.tw/brian/x16-music.png > >> >> > >> >> The artifacts are easily noticeable. The background image's gradients > >> >> are of 'big' steps. The artifacts are even more obvious on my > >> >> device's LCM, which is of lower DPI. Is it due to the colors or the > >> >> scaling? > >> >> > >> >> For the 'music' x11-16 screenshot, the text is all broken. IMHO, this > >> >> is due to my font, which is a truetype font with bitmaps info for > >> >> smaller font sizes (bitmap for smaller font and scaler for larger font > >> >> since scaler Chinese font look bad for small text). > >> >> > >> >> > > >> >> > For instance Canola2 use 16bpp which very colorful and rich visual. > >> >> > Actually I wrote 16bpp engine for Canola2 project and designers were > >> >> > always carefully checking all the details: > >> >> > > >> >> > http://openbossa.indt.org/canola2/ > >> >> > >> >> Yes, I've seen the demo. Very cool visuals. I just knew that it uses > >> >> 16bpp... > >> >> > >> >> > > >> >> > I'd recommend watching out rectangle colors that are supposed to match > >> >> > image colors. Remember that 16bpp is RGB565, that is 5 bits for both > >> >> > red and blue, 6 for green. So you basically discard the lower bits of > >> >> > each full 0-255 values in 32bpp. But for images we apply dithering > >> >> > when converting from 32->16 in order to avoid blocky gradients and > >> >> > such, for those cases you will likely get different color (1 value up > >> >> > or down) for each component based on nearby pixel. > >> >> > > >> >> > The safest thing to do is to calc 16bpp colors using: > >> >> > > >> >> > dr = (r >> 3) << 3 > >> >> > dg = (g >> 2) << 2 > >> >> > db = (b >> 3) << 3 > >> >> > > >> >> > The attached script should help you in your task. > >> >> > >> >> Do you mean that I have to manipulate each image to make it use only > >> >> the upper 5/6/5 bits for R/G/B? > >> >> > >> >> > >> >> > > >> >> > Again, send some screenshots so we can know what you mean. > >> >> > >> >> As above. > >> >> > >> >> Thanks. :-) > >> >> > >> >> > >> >> brian > >> >> > >> >> > > >> >> > -- > >> >> > Gustavo Sverzut Barbieri > >> >> > http://profusion.mobi embedded systems > >> >> > -------------------------------------- > >> >> > MSN: barbi...@gmail.com > >> >> > Skype: gsbarbieri > >> >> > Mobile: +55 (19) 9225-2202 > >> >> > > >> >> > >> >> > >> >> > >> >> -- > >> >> brian > >> >> ------------------ > >> >> > >> >> Cool-Karaoke - The smallest recording studio, in your palm, open-sourced > >> >> http://cool-idea.com.tw/ > >> >> > >> >> iMaGiNaTiOn iS mOrE iMpOrTaNt tHaN kNoWlEdGe > >> >> > >> >> ------------------------------------------------------------------------------ > >> >> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 > >> >> 30-Day trial. Simplify your report design, integration and deployment - > >> >> and focus on what you do best, core application coding. Discover what's > >> >> new with Crystal Reports now. http://p.sf.net/sfu/bobj-july > >> >> _______________________________________________ > >> >> 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 > >> > > >> > > >> > >> > >> > >> -- > >> brian > >> ------------------ > >> > >> Cool-Karaoke - The smallest recording studio, in your palm, open-sourced > >> http://cool-idea.com.tw/ > >> > >> iMaGiNaTiOn iS mOrE iMpOrTaNt tHaN kNoWlEdGe > >> > > > > > > -- > > ------------- 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 > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
