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

[Mihai Sucan]

Hello everyone!

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

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

-- 
Mihai Sucan
http://www.robodesign.ro