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