[Sugar-devel] Browse.xo performance & resolution - Hulahop 200dpi vs Browse 134dpi

[Lucian Branescu]

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.langhoff at gmail.com>:
> On Fri, May 15, 2009 at 9:56 AM, Martin Langhoff
> <martin.langhoff at 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.langhoff at gmail.com
>  martin at 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-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>