improvement in Font::drawText: fix or only workaround?

Stefan Heimers stefan at heimers.ch
Sat Mar 5 09:29:37 CET 2005


Hi,

I was reading the KDE CVS- Digest and found the following interesting 
optimization:

Description:
http://cvs-digest.org/?newissue=mar42005&type=Optimize

Code:
http://cvs-digest.org/?diff&file=kdelibs/khtml/rendering/render_text.cpp,v&version=1.267


In the last section you can find this:

// Due to some unfounded cause QPainter::drawText traverses the
// *whole* string when painting, not only the specified
// [pos, pos + len) segment. This makes painting *extremely* slow for
// long render texts (in the order of several megabytes).
// Hence, only hand over the piece of text of the actual inline text box
QConstString cstr = QConstString(str + pos, len);
p->drawText( x, y, cstr.string(), 0, len, d );


It's a good thing that there was a problem discovered and speed 
improved. But I have three questions:

1) There is an additional QConstString element created.  Will this be 
automagically freed when not needed anymore? Or should it be deleted 
after the p->drawText?
I think it's automatically deleted because it is local to the 
Font::drawText, but I am not sure because I don't know Qt and C++ 
enough. 

2) Reading the comment it seams like a bug in Qt rather than khtml. 
Shouldn't it better be fixed in Qt or is there a good reason for Qt's 
behaviour? With a fix in Qt, you wouldn't need to create this 
unnecessary QConstString cstr and the fix would help everywhere, not 
only in Font::drawText.

3) It could be that the workaround makes things better for very large 
strings, but even worse for small strings. And small strings are quite 
more common than 8MB <div> sections on ordinary html pages.

Stefan



More information about the Kde-optimize mailing list