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.
Sugar-devel mailing list

Reply via email to