HTML Canvas performance in the Browse activity

Sun May 31 13:10:49 EDT 2009

On Sun, May 31, 2009 at 18:48, Mihai Sucan <mihai.sucan at gmail.com> wrote:
> Hello everyone!
>
> I am Mihai Sucan, and I am working over the summer to develop and
> integrate a paint tool [1] into Moodle. [2] I am also involved in doing
> performance testing on the XO laptop.

Thanks a lot for your nice work untangling this mess. I'm forwarding
this email to sugar-devel because I guess you want the Sugar
developers be aware of this.

Let me ask you a couple of questions:

- which version(s) of Sugar targets your project?

- already have an idea about how are going to be deployed any
modifications that result from this?

Thanks,

Tomeu

> HTML 5 [3] has a new Canvas element [4] which provides an API for bitmap
> drawing operations on a bidimensional surface. Rendering is generally
> quite fast on desktop Web browsers, and it requires no plugins like Flash
> or Java.
>
> = The problem =
>
> On the XO OS 8.2.x, and probably on older versions, HTML Canvas
> performance is most often very slow because the default Browse activity is
> configured to scale pages. Typically, pages are rendered using 96 DPI in
> Web browsers, but on the XO the browser renders the pages using 134 DPI.
> This ensures the text and images are still readable - otherwise they'd be
> far too small because the XO display [5] has a high DPI resolution.
> Nonetheless, scaling images up is quite slow - the high-quality bilinear
> filter is used. This impacts the overall performance of the browser and
> moreso the performance of the Canvas element.
>
> The Browse activity uses the xulrunner package [6], which contains the
> Gecko layout engine [7] version 1.9.0 (the same as in Firefox 3.0).
>
> Users can change the DPI used for rendering a page by going to
> about:config, where they can modify the layout.css.dpi value. Yet, Hulahop
> includes some piece of puzzling code [8] which always resets the
> layout.css.dpi configuration value to 134.
>
> The xulrunner package includes a patch [9] which alters the page scaling
> logic [10] in Gecko. This patch makes a simple, yet important change to
> how the DPI config value is used for scaling the page being rendered. A
> normal Gecko build only scales pages using an integer scaling factor, but
> on the XO the scaling factor can also be a floating-point number. This
> means that a normal Gecko build uses a scale factor of 1 for DPI < 192,
> and a scale factor of 2 for 192 <= DPI <= 288, and so on.
>
> = Patches =
>
> Gecko 1.9.1 includes a patch [11] which adds a new config option
> layout.css.devPixelsPerPx. This allows OLPC to configure the browser such
> that physical units render properly scaled using the correct DPI value,
> but not the CSS pixel values. CSS pixels could be equal to device pixels -
> they would all render small, but much faster.
>
> Another Gecko patch worth being noted is the CSS image-rendering property
> support [12]. This would allow Web developers to tell Gecko to use
> nearest-neighbour instead of bilinear interpolation for the scaling of
> elements.
>
> = Solutions =
>
> The XO browser has two problems actually: 1) performance issue caused by
> scaling everything up; 2) the difference in the scaling logic from a
> normal Gecko build.
>
> Problem 1: Having everything render using 96 DPI is not acceptable - pages
> would be unreadable. I would suggest that Gecko on the XO scales images
> using a faster algorithm instead of the bilinear one. It would also be
> interesting to experiment with the new layout.css.devPixelsPerPx
> configuration set to 1. Maybe hardware acceleration in newer XOs?
>
> Problem 2: Keeping the current 134 DPI value would always require Gecko to
> be patched, thus making it different from other Gecko builds. Maybe the
> browser could use 200 DPI? Perhaps pages would render too big.
>
> A different line of thought would be: "why complain about problem 2?" I
> mean, Web developers are not supposed to be tinkering with DPI in their
> Web pages - it's the problem of the browser.
>
> As a Web developer I do not mind about problem 2 if problem 1 is fixed.
> Problem 2 is important only when trying to work around problem 1.
>
> = Work around =
>
> It's simple: you need to scale down the Canvas element such that Gecko
> cancels the scaling. However, you need to find out the DPI used for
> rendering the page. You can do this only by using CSS 3 Media Queries [13].
>
> Gecko has support for floating-point pixel values, so there's nothing to
> worry about values being floating-point numbers. The work around I came up
> with is described at:
>
> http://wiki.laptop.org/go/HTML_canvas_performance#Work_around
>
> This work-around is not ideal simply because it would be best if the
> Browse activity would be faster by default. What do you guys think? Is
> there something that can be done? The performance improvement is far from
> being marginal when the work-around is used.
>
>
> Sorry for this lengthy email. ;)
>
>
> (I have posted this on the wiki as well for further reference to others
> who need help with Canvas on the XO)
>
>
> References:
>
> [1] http://code.google.com/p/paintweb
> [2] http://www.moodle.org
> [3] http://www.whatwg.org/specs/web-apps/current-work/multipage/
> [4]
> http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html
> [5] http://wiki.laptop.org/go/Display
> [6] http://koji.fedoraproject.org/koji/buildinfo?buildID=60150
> [7] http://en.wikipedia.org/wiki/Gecko_(layout_engine)
> [8]
> http://dev.laptop.org/git/projects/hulahop/diff/python/__init__.py?id=32a18dfc6da97801673dd0bf7424350489694ca0
> [9]
> http://koji.fedoraproject.org/koji/fileinfo?rpmID=715226&filename=xulrunner-olpc-pre-dpi.patch
> [10] https://wiki.mozilla.org/Mozilla2:Units
> [11] https://bugzilla.mozilla.org/show_bug.cgi?id=493202
> [12] https://bugzilla.mozilla.org/show_bug.cgi?id=486936
> [13] http://www.w3.org/TR/css3-mediaqueries/#resolution
>
>
> --
> Mihai Sucan
> http://www.robodesign.ro
> _______________________________________________
> Devel mailing list
> Devel at lists.laptop.org
> http://lists.laptop.org/listinfo/devel
>