On Thu, Nov 12, 2009 at 4:44 PM, Brian Wang <[email protected]> wrote: > [ snip ] >> Damn, you did fall in the following bugs: >> >> - no smooth scaling for 16bpp: background is very noticeable with >> that, as well as some icons and even the elementary clock parts. The >> reason is: before there was no scale cache, thus there was no meaning >> in keep doing scale of UI parts, thus things like scaling were just >> used during effects or photos, real UI elements were designed to fit >> their screens and never scale (so faster, pixel perfect). >> - images with transition colors get "bands": as said before, if you >> have some gradient that is very small difference from color A to color >> B, then the missing resolution (lost bits from R, G, B) are easy to >> spot. Together with problem 1 (no smooth scaling) mentioned above, it >> will look like crap. Instead, just avoid using these gradients where A >> and B are too close. >> >> the first point is fixable, just need someone with time and motivation >> to do so (I have none). The second is not, needs help from design >> team. Well, design team could solve both problems, as you really >> should not be rescaling your interface elements. >> >> Last but not least, don't use text effects: they are slow. > > OK. I'll have my design team take a shot at it. > >> >> >>>> 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... >> >> As I said before, you need to do design together with development, one >> needs to help the other and then you have good software. >> >> You can trade this care and waste more CPU, doing dithering to solve >> band problems by using 32bpp engine. In some cases you don't have many >> fancy effects and cpu is not a problem. >> >> >>>> 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? >> >> If you change them, they'll likely suck as well (designers did try >> some tricks to convert images to "rgb565" in photoshop without luck). >> You need to design your system using these limits in mind. >> >> 1 - Avoid gradients from colors that vary around the lost bits. If >> before you had a gradient from gray 220 to 240, or 20 levels to play >> with. So 220,220,220 in 32bpp is already inexistent in 16bpp, run the >> script and discover 216,220,216 is all you have!!! Of course, this is >> green-ish and not gray as expected, first thing to fix and use >> 216,216,216 instead. If you run: >> >> for n in `seq 220 240`; do rgb16bpp.py $n $n $n; done | grep 16bpp | >> uniq >> >> from the initial 20 levels, all you get are 6 different levels!!! If >> you had 80 pixels to spread this, before you'd change the color every >> 4 pixes, now every 13, much easier to notice... even more if the color >> is bit green nown and then. >> >> 2 - Avoid light colors, specially gray->white where all components >> must be the same. Using light colors you're likely to reach color >> boundaries and human eyes will be likely to spot problems. As said >> before, this is even more visible with gray that gets more green than >> other colors >> >> 3 - Try to use the color that you have more bits, that is, green. This >> is hard, I know, but can bring some benefits. >> >> >> Looking at what I wrote, you might wonder "oh my god, impossible". But >> if you try to do an Palm Pre like user interface with 16bpp it will >> look just nice! Just get a great picture with various colors and sharp >> transitions (then avoiding gradient), add semi-transparent black >> background with UNSCALED lightning details images on top (like >> elementary buttons). > > Yeah. The devil is in the details. > > Thank you for all the great tips. These are invaluable info for > embedded software and artwork designers. > Maybe a wiki page for these?
feel free to write it :-) I'm not much into writing... and although I keep telling people these free advices, my company works selling consulting that covers it and more :-) -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: [email protected] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
