Le Sun, 17 May 2009 14:30:16 +0300, Lucian Branescu
lucian.brane...@gmail.com a écrit:
Does anyone know how gecko 1.9.1's full page zoom interacts with
canvas?
Please be more specific.
As far as I know, zooming is applied transparently - the Web application
does not observe the changes.
Does anyone know how gecko 1.9.1's full page zoom interacts with canvas?
2009/5/16 Albert Cahalan acaha...@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
I was thinking whether it has some scaling optimisations, since it
does a lot of it with the zoom.
2009/5/17 Mihai Sucan mihai.su...@gmail.com:
Le Sun, 17 May 2009 14:30:16 +0300, Lucian Branescu
lucian.brane...@gmail.com a écrit:
Does anyone know how gecko 1.9.1's full page zoom interacts
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
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.langh...@gmail.com:
On Fri,
Qt on Maemo's problem was similar, but not quite the same.
http://ariya.blogspot.com/2008/08/qt-44-and-maemo.html
Qt used 32bit colors internally, but Maemo could only output 16bit. So
Qt was forced to convert between the two all the time. The solution
was to allow Qt to use 16bit internally,
Hi OLPCistas, Sugaristas,
Mihai (GSoC participant on the Moodle side of things) has been
experimenting with Browse.xo and the performance of its canvas
implementation.
Out of the box, it is awfully slow (while other aspects of Browse are
fairly optimised).
He tells the story here, including
Hello everyone!
Le Fri, 15 May 2009 10:56:20 +0300, Martin Langhoff
martin.langh...@gmail.com a écrit:
Hi OLPCistas, Sugaristas,
Mihai (GSoC participant on the Moodle side of things) has been
experimenting with Browse.xo and the performance of its canvas
implementation.
Out of the box,
On Fri, May 15, 2009 at 9:56 AM, Martin Langhoff
martin.langh...@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
Le Fri, 15 May 2009 15:26:42 +0300, Lucian Branescu
lucian.brane...@gmail.com a écrit:
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
10 matches
Mail list logo
