Browse.xo performance & resolution - Hulahop 200dpi vs Browse 134dpi

Martin Langhoff martin.langhoff at
Fri May 15 03:56:20 EDT 2009

Hi OLPCistas, Sugaristas,

Mihai (GSoC participant on the Moodle side of things) has been
experimenting with Browse.xo and the performance of its canvas

Out of the box, it is awfully slow (while other aspects of Browse are
fairly optimised).

He tells the story here, including performance profiling comparisons
with Webkit, Browse and Opera:

The short version of it is that canvas (and image rendering in
general) is hurting lots due to the dpi being hardcoded to 134 which
forces Gecko into image scaling games. Just setting layout.css.dpi to
96 makes Browse much snappier in general, and incredibly faster in
canvas painting.

It also makes pages unreadably small though.


- I am intrigued, hulahop sources say it's hardcoded to 200dpi (and
that jives with our screen) - why does it end up being 134? Should it
be 200dpi? Would that hit the fast paths properly? (Mihai: does 200dpi
make it better?)

- Do we need to set something else in hulahop, gecko sources or Browse
so that the gecko internals know what dpi to create the canvas at, to
ensure we avoid scaling (and so hit the fast paths)?

Crossposting to both lists as this crosses all the stack, and people
knowledgeable in this are split across the lists ;-)


 martin.langhoff at
 martin at -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first

More information about the Devel mailing list