This is very interesting, similar to the problem Qt used to have on Maemo. I was always surprised by report of <canvas> being slow on the XO, it's probably the fastest and the lowest overhead drawing technology available to JavaScript.
2009/5/15 Martin Langhoff <martin.langh...@gmail.com>: > On Fri, May 15, 2009 at 9:56 AM, Martin Langhoff > <martin.langh...@gmail.com> wrote: >> - 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?) > > At least that part of the mystery is solved -- hulahop checks whether > dpi == 200dpi, and in that case... sets the dpi to 134. See > _get_layout_dpi here: > http://dev.laptop.org/git/projects/hulahop/diff/python/__init__.py?id=32a18dfc6da97801673dd0bf7424350489694ca0 > > Marco, do you remember where the magic 134 came from? > > Still chasing up why canvas rendering goes through the floor @ 134... > > cheers, > > > > m > -- > martin.langh...@gmail.com > mar...@laptop.org -- School Server Architect > - ask interesting questions > - don't get distracted with shiny stuff - working code first > - http://wiki.laptop.org/go/User:Martinlanghoff > _______________________________________________ > Sugar-devel mailing list > sugar-de...@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
