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

[Martin Langhoff]

Hi OLPCistas, Sugaristas,

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

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:
http://www.robodesign.ro/mihai/blog/paintweb-code-refactoring-and-more

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.

Questions:

- 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 ;-)

cheers,



m
-- 
 martin.langhoff at gmail.com
 martin at laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff