Tux Paint

From OLPC
Revision as of 03:26, 12 March 2007 by AlbertCahalan (talk | contribs)
Jump to: navigation, search
Tux Paint on the OLPC XO
view in full resolution to see screen detail

Tux Paint

Tux Paint is a drawing app for tiny kids. Most 3-year-old kids and many 2-year-old kids are able to use it, yet 10-year-old kids (and kid-like adults) enjoy it too. Tux Paint features Tux the penguin, like Clippy but not so annoying. Tux Paint uses stereo sound according to where the mouse pointer is. Tux Paint is translated into about 40 different languages, including big-alphabet and right-to-left ones.

Port situation

Tux Paint is now able to survive on the B2 hardware. Very little of the 128 MB of RAM is available, so the kernel's OOM killer likes to kill the current app. CSound gobbles about 20 MB, yet doesn't let Tux Paint play sound. Sugar itself, despite being really spartan, takes about 8 MB. About 75 MB goes missing before Tux Paint even gets a chance.

The current 5:6:5 RGB is a problem for Tux Paint. Long ago, Tux Paint used that mode. The uneven bit allocation caused images to change colors when 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. The display controller chip probably should use temporal dithering to overcome the 6:6:6 limit of the LCD panel. 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.

SVG can not be supported without the svg.h and svg-cairo.h header files. Trying to get these via yum results in a failed attempt to bring in everything under the Sun, including GNOME!!! Somebody really needs to fix all the false dependencies in Fedora.

Tux Paint already had blurry text in the UI via scaling, so the XO's unusual screen doesn't really hurt.

Security needs

Tux Paint wants to print, scan /usr/share/fonts, and cooperate with a separate clip-art package.