User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:188.8.131.52) Gecko/20060207 Camino/1.0rc1+ Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:184.108.40.206) Gecko/20060207 Camino/1.0rc1+ camino takes about a second whereas FF1.5 is almost instant, possibly 4-10 times faster. Reproducible: Always Steps to Reproduce: 1.mouse over links 2. 3. Actual Results: border appears and text changes I am attaching a file which is about 1/4 the size of the URI bit probably too large to immediately catch the issue. sorry this isn't smaller, so this may remain a curiosity for a while...
I do notice that we seem a little slower than Fx in updating color or word changes once moused-over, but it's almost unnoticeable (esp. on the larger SVG in the URL). Simon, is this just our drawing and the opacity/fighting between Gecko and AppKit, or might this be an issue we should push up to to the Gecko folks about performance of SVG in embedding apps?
Summary: camino slower than FF to update SVG → camino slower than FF to update SVG (change elements on mouse-over)
When I profile, most of the time is spent in cairo (see bug 324944), but we may be drawing more than FF is becuase of the AppKit/widget and non-opaque views issues.
Opera 9 is significantly quicker to load and more responsive for instance to onmouseover. also see: https://bugzilla.mozilla.org/show_bug.cgi?id=324944
I can't see any difference between Camino and Firefox either, so duping this to bug 324944 based on comment 3. *** This bug has been marked as a duplicate of 324944 ***
Status: UNCONFIRMED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → DUPLICATE
cheers, apologies for not closing this myself...
You need to log in before you can comment on or make changes to this bug.