On Thu, Nov 12, 2009 at 2:07 AM, Brian Wang <brian.wang.0...@gmail.com> wrote: > [ 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). > > 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).
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. >> 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). BR, -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: barbi...@gmail.com 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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
