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

[Lucian Branescu]

Does anyone know how gecko 1.9.1's full page zoom interacts with <canvas>?

2009/5/16 Albert Cahalan <acahalan at gmail.com>:
> Martin Langhoff writes:
>
>> 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.
>
> This was discovered when scaling was first enabled.
>
> One could write a special-case scaler for that DPI,
> avoiding the more generic scaling code.
>
> The XO also suffers from 5:6:5 pixel layout, which requires
> lots of bit shifting.
>
>> It also makes pages unreadably small though.
>
> It's not just the size. The XO screen purposely smears the pixels
> to reduce color fringing.
>
>> 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?
>
> 134 puts 860x645 web pixels on the screen. We do this partly because
> it is enough pixels for most modern web pages, and partly because of
> a persistant myth that the XO screen resolution is equal to 800x600.
> In other words, it's an arbitrary number with feeble justification.
>
> There are at least two reasonable ways to deal with this problem.
>
> The first way is to use the hardware scaling. This involves telling
> the X server to change screen resolution. Sugar would need to manage
> this on a per-activity basis, with adjustments to the frame as needed.
> Besides elimination of scaling, the browser would move fewer pixels
> and need less memory. It'd be amazing for performance. A downside is
> that text would be less sharp, both from the scaler operation and more
> directly from having fewer pixels.
>
> The second way is to choose a scaling factor that is easy to optimize,
> and then do so. Easy would be 128 (3:4 ratio, 900x645 web pixels) or
> 144 (2:3 ratio, 800x600 web pixels). You could optimize both, along
> with 192 (1:2 ratio, 600x450 web pixels), and let users get a choice.
> Unscaled can be an option too.
>