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 -- [email protected] [email protected] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff _______________________________________________ Devel mailing list [email protected] http://lists.laptop.org/listinfo/devel
