[ 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? Thank you. brian > > > BR, > -- > 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
