Re: [Sugar-devel] Browse.xo performance & resolution - Hulahop 200dpi vs Browse 134dpi
Le Sun, 17 May 2009 14:30:16 +0300, Lucian Branescu a écrit: > Does anyone know how gecko 1.9.1's full page zoom interacts with > ? Please be more specific. As far as I know, zooming is applied "transparently" - the Web application does not "observe" the changes. Dimensions of all elements, including the canvas element, remain the same. This is similar to changing the DPI. Obviously, drawing on the canvas is slower, since the canvas image needs to be scaled to the zoom level. -- Mihai Sucan http://www.robodesign.ro ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Browse.xo performance & resolution - Hulahop 200dpi vs Browse 134dpi
I was thinking whether it has some scaling optimisations, since it does a lot of it with the zoom. 2009/5/17 Mihai Sucan : > Le Sun, 17 May 2009 14:30:16 +0300, Lucian Branescu > a écrit: > >> Does anyone know how gecko 1.9.1's full page zoom interacts with ? > > Please be more specific. > > As far as I know, zooming is applied "transparently" - the Web application > does not "observe" the changes. Dimensions of all elements, including the > canvas element, remain the same. This is similar to changing the DPI. > Obviously, drawing on the canvas is slower, since the canvas image needs to > be scaled to the zoom level. > > > > > -- > Mihai Sucan > http://www.robodesign.ro > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Browse.xo performance & resolution - Hulahop 200dpi vs Browse 134dpi
Does anyone know how gecko 1.9.1's full page zoom interacts with ? 2009/5/16 Albert Cahalan : > 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 Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Browse.xo performance & resolution - Hulahop 200dpi vs Browse 134dpi
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 Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Browse.xo performance & resolution - Hulahop 200dpi vs Browse 134dpi
This is very interesting, similar to the problem Qt used to have on Maemo. I was always surprised by report of being slow on the XO, it's probably the fastest and the lowest overhead drawing technology available to JavaScript. 2009/5/15 Martin Langhoff : > On Fri, May 15, 2009 at 9:56 AM, Martin Langhoff > 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-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Browse.xo performance & resolution - Hulahop 200dpi vs Browse 134dpi
On Fri, May 15, 2009 at 9:56 AM, Martin Langhoff 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-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
