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

Mihai Sucan mihai.sucan at
Fri May 15 05:50:24 EDT 2009

Hello everyone!

Le Fri, 15 May 2009 10:56:20 +0300, Martin Langhoff  
<martin.langhoff at> 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
> 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:
> 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?)

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.

Best regards,

Mihai Sucan

More information about the Devel mailing list