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

[Lucian Branescu]

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, which was done for Qt 4.5

It is possible that Gecko has some options to allow it to draw fast at
various DPI settings. Maybe we should ask the mozilla folk?

2009/5/15 Mihai Sucan <mihai.sucan at gmail.com>:
> Le Fri, 15 May 2009 15:26:42 +0300, Lucian Branescu
> <lucian.branescu at 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 technology
>> available to JavaScript.
>
> It's true it's the fastest and the lowest overhead drawing technology
> available to JavaScript - which is really the reason I picked it for the
> development of the paint tool.
>
> I wouldn't agree with the idea of Canvas being actually (too) slow on the
> XO, nor on desktops. Once I changed the DPI to 96 on the XO, I was rather
> amazed / very pleased by the performance of the drawing tool. It's almost as
> fast as on the desktop.
>
> Surely, the Canvas drawing performance should be something we all desire to
> improve, constantly. ;) Yet, it looks like the main performance hit on the
> XO comes from the DPI setting. The bilinear rescaling of the Canvas element
> being performed by Gecko slows things very much. We need to work around this
> issue somehow.
>
> Would the experience of making Qt faster on Maemo provide us with anything
> of use in this case? (it seems to me it's unlikely, but ... it never hurts
> to ask)
>
>
> --
> Mihai Sucan
> http://www.robodesign.ro
>