[Webkit-unassigned] [Bug 30055] Bad DOM performance in large SVG files

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Sun Nov 15 15:01:07 PST 2009


https://bugs.webkit.org/show_bug.cgi?id=30055





--- Comment #17 from Oliver Hunt <oliver at apple.com>  2009-11-15 15:01:06 PST ---
(In reply to comment #16)
> (In reply to comment #15)
> > WebCore uses the platform's graphics library, if that graphics library has bad
> > perf in some cases it can easily cause all sorts of badness.  I'm unsure
> > whether the solution should be to get Qt to fix this issue (presumably it's a
> > problem in their graphics library) or fix it in WebCore itself (which may
> > negatively impact performance of other platforms)
> > 
> > Maybe this logic should be in GrpahicsContextQt?
> Do you think rendering anything ist better than checking if it is necessary? I
> think WebCore should render as least as possible. In GrpahicsContextQt there
> won't be any information to check if painting is required. Rely on a "perfect
> performing" graphics library isn't the right way in opinion. There might be
> some other ports with slow graphics librarys too.

The problem is that if the underlying graphics library is already doing the
tests it may have a more efficient way of doing so, add to that the fact that
the underlying graphics libraries that do perform sensible clipping
optimisations will still be doing their own clip tests this seems like a patch
that has bad perf impact on good libraries to deal with poor performance in
others.

I suspect if we really do want webcore to work around what is arguably a perf
bug in Qts graphics subsystem the fix should be placed in GraphicsContextQt
directly

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the webkit-unassigned mailing list