André Pönitz wrote: > LyX is the _only_ application I know that e.g. still pretends to be able > to draw outside of paint events by adding another level of buffering > (GuiWorkArea::Private::screen_). And note, that's not a "problem > originating from Qt", but imposed by some platforms, most notably > MacOS_X_. This approach causes otherwise completely unnessary copies of > all screen data when scrolling. > > Also, the core text drawing functionality is "abstracted", i.e. LyX does > it (deteminining positioning, spacing etc), spoon-feeds the results to > Qt's drawText() which does the same again. Similar for the handling of > fonts, colors etc. > > I just stepped a bit through the code and there were tons of instances > where single characters were passed to drawText, each setting up the > text drawing machinery mostly from scratch. I do understand that this > might be needed for math, but it should not happen often for regular > test.
my point was that its not clear at all whether all this is culprit of the problems. on contrary i have seen many reports which cast doubt on different layers of the system. when people report 90% of cpu time taken by X how much of total time is taken from lyx by internal computations? right now i'm siting on my home system which by top shows 80 (X) :17 (lyx) when holding down arrow. typing is so-so, scrolling is pain but one get used to it after some time. launching sysprof leads to 72:16, main eaters all lead to various radeon routines in kernel (at least 45). (195.113.26.193/~sanda/prof.tgz) there were more reports like this, and i have already sent more profiles with similar findings. sure, one can't rule out the possibility that we abuse qt somehow but it doesn't look like that. when i run ooffice (or firefox etc) and scroll no such problems, so the drivers are not always bottleneck. pavel
