Browse.xo performance & resolution - Hulahop 200dpi vs Browse 134dpi
mihai.sucan at gmail.com
Fri May 15 05:50:24 EDT 2009
Le Fri, 15 May 2009 10:56:20 +0300, Martin Langhoff
<martin.langhoff at gmail.com> a écrit:
> 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?)
I have tested this right now. No, it doesn't. The entire Web application
render bigger, obviously (200dpi versus 134dpi). Yet, the performance is
still very bad.
I tried setting layout.css.dpi to -1 as well. This lets Gecko choose the
default DPI of the OS. That's 200 DPI. Same performance issues.
The browser seems to reset the layout.css.dpi value to 134 every single
time I start it. It won't remember my changes.
More information about the Devel