On Mon, 2007-03-12 at 03:22 -0400, Albert Cahalan wrote: > Long ago, Tux Paint used 5:6:5. This caused colors to get messed up if > the user did repeated blur, smudge, pixelate, and similar operations. > Tux Paint normally uses 8:8:8 RGB, with occational 32:32:32 (linear float) > RGB for troublesome blending operations like smudge. The version that > runs on the B2 OLPC XO is currently using 5:5:5, but this causes lots of > conversions that require bit shifting. The situation would be much better > if the XO used 5:5:5 or 8:8:8. While 8:8:8 is 50% bigger, it avoids lots > of bit shifting (very slow on many processors) and preserves information.
You're completely correct. > Eliminating the use of 32:32:32 will probably involve linear integer data, > 16:16:16 on normal hardware at least, perhaps with MMX via gcc's vector > support. This wouldn't be 5:6:5 either. > > If I recall right, eToys was using 5:5:5 and GDK uses 8:8:8. > Switching to one of those would be good. 5:6:5 can't even do grey. > Not that non-linear data is any good for computation... Sugar doesn't really use GDK, it uses hippo-canvas and cairo. But neither cairo or GDK really work well at 555. > The display controller chip probably should use temporal dithering to > overcome the 6:6:6 limit of the LCD panel. This would make 8:8:8 much > more valuable. Ideally we'd like to switch to 1555 with a framebuffer format of 555. We've did a lot of performance profiling in January and February at 565 and determined that format conversions in X suck and are killers. We decided that either 1555 or 4444 were the best options, respectively. Ideally we would switch to 1555. Here are the reasons that hasn't happened yet: 1) We haven't had the time to profile 1555 to see if it really would make a noticeable difference. You can't take something like this on faith, you really have to get numbers to prove it. 2) The 1555 paths in X11's and cairo's pixman are not MMX-optimized like the 565 paths are. This means that somebody has to write the MMX optimized routines for pixman before we'd ever really get useful benchmarks for #1 above. The most useful ones are 8888 -> 1555 conversions of course. 3) Cairo doesn't have support for 1555, and it only grudgingly uses 565 when the backing Xlib visual is a 565 surface. Native 1555 would mean implementing 1555 support in cairo as well. 4) We've been able to fairly easily spot-optimize the pieces of Sugar that were being really slow, which at _this_ point, with a variety of test releases in the very very near future, was a better use of our time than a few weeks on MMX and cairo. But since it's an infrastructure change, it can be done at any time without really affecting the actual GUI stack. 5) This is a highly parallelized, focused task that is orthogonal to the rest of the project, that somebody could "own" quite easily. But the benefits would be large. If somebody can do MMX, you only need to write the pixman routines once because both cairo and X use essentially the same sources for MMX accel. In short, yes, 1555 is the best option for now, but requires a lot of work to get to the point of benchmarking and profiling it to see if it really noticeably faster and better. Dan _______________________________________________ Devel mailing list [email protected] http://mailman.laptop.org/mailman/listinfo/devel
