[webkit-dev] restructuring, kwq and QPainter

[Maciej Stachowiak]

Hi Leo,

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  
CoreGraphics.

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  
reconsider.

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.

Regards,
Maciej