Help with testing a patch for xulrunner...

[Martin Langhoff]

Hi list,

while working on a webbased project (as part of the OLPC School
Server), we're hitting on a performance bug / oddity with Browse.xo
(which is the sugarised face of xulrunner on the XO) on the 8.2
release.

Rob O'Callahan proposes we test a patch (attached) to see if things
get better. Can anyone help with this? The xulrunner we ship on 8.2
has some OLPC-specific patches, and I'd hope to add this patch to the
pile.

I couldn't find the spec or srpm, but here's the Koji task. Presumably
it's retrievable from there?
http://koji.fedoraproject.org/koji/taskinfo?taskID=783777

cheers,


martin

---------- Forwarded message ----------
From: Robert O'Callahan <robert at ocallahan.org>
Date: Fri, May 15, 2009 at 1:07 PM
Subject: Re: Browse.xo performance & resolution - Hulahop 200dpi vs
Browse 134dpi
To: Mihai Sucan <mihai.sucan at gmail.com>
Cc: Martin Langhoff <martin.langhoff at gmail.com>


On Fri, May 15, 2009 at 10:54 PM, Mihai Sucan <mihai.sucan at gmail.com> wrote:
>
> Le Fri, 15 May 2009 13:22:15 +0300, Robert O'Callahan <robert at ocallahan.org> a écrit:
>
>> Another thing we could do is implement what I suggested here:
>> https://bugzilla.mozilla.org/show_bug.cgi?id=394103#c53
>> That would let you set the dpi to the correct value (so physical units,
>> including fonts in pt, display correctly) but force images and canvases (and
>> other CSS px units) to not be scaled. They'd be too small, but fast :-).
>
> This is what would be best.

OK, I'll do that.

> Another idea is to have some CSS property to disable scaling entirely for the canvas elements I want.

I don't really want to do that, because I don't want Web developers to
write applications that depend on zoom or dpi.

If you're willing to assume you're 200dpi, you can just write <canvas
width="200" height="200" style="width:100px; height:100px;"> ...
suboptimal though.

I don't know if you can apply a patch to Gecko, but if you can, the
attached patch would let us render the <canvas> in a local surface
instead of using X. That should provide a speedup in your benchmarks,
where X isn't giving much hw acceleration and you're doing a large
amount of drawing operations and hardly any displaying to the screen.
I'd be interested to hear what effect it has. However, in real-world
usage I imagine the canvas is drawn to the screen far more often
compared to the number of drawing operations, so this patch might not
make sense for actual users.

Rob
--
"He was pierced for our transgressions, he was crushed for our
iniquities; the punishment that brought us peace was upon him, and by
his wounds we are healed. We all, like sheep, have gone astray, each
of us has turned to his own way; and the LORD has laid on him the
iniquity of us all." [Isaiah 53:5-6]



-- 
 martin.langhoff at gmail.com
 martin at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch
Type: application/text
Size: 1004 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-olpc-list/attachments/20090519/ba2e7062/attachment.bin>