[webkit-dev] restructuring, kwq and QPainter
mjs at apple.com
Fri Feb 24 12:11:45 PST 2006
On Feb 24, 2006, at 9:23 AM, Leo Savernik wrote:
> Due to the latest restructurings of WebCore am I right of the
> impression that
> Apple is going to outphase kwq completely?
Yes, that's our current plan.
> In this case I have to remark that painting is a speed-critical
> path in khtml
> used under KDE. Therefore I propose that the painting routines of
> the render
> tree are not replaced by another abstraction layer, but staying as
> close as
> possible to Qt4's QPainter (with provisions for platform-dependent
> extensions, of course).
I understand your concern. But I don't think the abstraction layer
will introduce a performance penalty. On Mac OS X we've had an
abstraction layer from QPainter to CoreGraphics since we started the
project. Earlier, much of the code actually went through double
indirection, from QPainter to AppKit Objective-C classes, to
We regularly do detailed profiling and we have never found the
abstraction layer to incur a speed penalty. There are practically no
samples in the wrapper functions. All the time for graphics
operations is spent in the actual low-level graphics code, doing
things like blitting, drawing glyphs, measuring text, etc.
It may be that for KDE the abstraction layer will actually incur a
speed penalty, whereas on Mac OS X it doesn't. But I think this is
highly unlikely. If we saw actual measuements to that effect we could
Another thing to keep in mind is that having the abstraction layer
makes it easier to experiment with other graphics systems. For
example, it may be that even for the KDE port using a library like
Amarinth or Cairo would be faster than the native QPainter. The
graphics abstraction will make it easier to try this while still
linking to Qt.
More information about the webkit-dev