Hello everyone! Le Fri, 15 May 2009 10:56:20 +0300, Martin Langhoff <[email protected]> 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 _______________________________________________ Devel mailing list [email protected] http://lists.laptop.org/listinfo/devel
