HTML Canvas performance in the Browse activity

[John Gilmore]

I suspect that the reason relates to the OLPC's unique screen.  The
physical pixels are spaced at 200 per inch horizontally and
vertically.  But there's only one color per pixel, not three.  Each
pixel lights up in a particular color.  In a 'red' pixel, the green
and blue sub-values from the frame buffer are ignored (but they get
averaged into a nearby blue pixel by the dcon chip).

(In 'normal' 96 dpi screens they actually have three subpixels
horizontally (red, green, and blue), so the resolution in the
horizontal direction is almost 300 dpi while vertically it's only 96
dpi.)

Perhaps it's that you'd like the software to draw very crisp text by
knowing that the screen really renders 200 dpi, but draw pictures at
some lower dpi like 134, knowing that you can't represent all the
colors in the original pixels unless you enlarge it somewhat.

> The XO browser has two problems actually: 1) performance issue caused by  
> scaling everything up; 2) the difference in the scaling logic from a  
> normal Gecko build.
> Problem 2: Keeping the current 134 DPI value would always require Gecko to  
> be patched, thus making it different from other Gecko builds. Maybe the  
> browser could use 200 DPI? Perhaps pages would render too big.

Is there a good reason that the upstream Gecko maintainers wouldn't
take this a patch, or one like it?  As long as the scale factor is 1
on ordinary screens (and the code optimizes that path), adding this
would have little impact on speed or space on non-OLPCs.  (And if
Pixel Qi succeeds in selling their screens, there are going to be more
'unusual' cheap & high performance screens that we'll want good free
software support for.)

	John