Re: Report (was: Qt: was Slow scrolling)
On Thu, Jan 05, 2012 at 02:17:29PM +0100, Pavel Sanda wrote: Jean-Marc Lasgouttes wrote: Le 05/01/2012 02:40, André Pönitz a écrit : The main performance problems I have seesn so far are due to an abuse of the toolkit, not caused _by_ the toolkit (except for the remote raster please... there were many cases we have no clue where the problem is. it can be lyx, qt, X, card drivers. to summarize the whole thing by saying that all is abuse of qt smells like problem with your affiliation ;) [Sure, we can go ad hominem if you think that helps...] 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. Andre'
Re: Report (was: Qt: was Slow scrolling)
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
Re: Report (was: Qt: was Slow scrolling)
On Thu, Jan 05, 2012 at 02:17:29PM +0100, Pavel Sanda wrote: > Jean-Marc Lasgouttes wrote: > > Le 05/01/2012 02:40, André Pönitz a écrit : > >> The main performance problems I have seesn so far are due to an abuse of > >> the toolkit, not caused _by_ the toolkit (except for the remote raster > > please... there were many cases we have no clue where the problem is. > it can be lyx, qt, X, card drivers. to summarize the whole thing by saying > that all is abuse of qt smells like problem with your affiliation ;) [Sure, we can go ad hominem if you think that helps...] 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. Andre'
Re: Report (was: Qt: was Slow scrolling)
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
Report (was: Qt: was Slow scrolling)
Jean-Marc Lasgouttes wrote: Le 05/01/2012 02:40, André Pönitz a écrit : The main performance problems I have seesn so far are due to an abuse of the toolkit, not caused _by_ the toolkit (except for the remote raster please... there were many cases we have no clue where the problem is. it can be lyx, qt, X, card drivers. to summarize the whole thing by saying that all is abuse of qt smells like problem with your affiliation ;) painter problem perhaps). Just start at RowPainter::paintChars() and walk down through all the mess _before_ it actually hits Qt's drawText() It is slow? You bet. The question is whether the Xorg takes 90% cpu complaints will go away with Abdel new patch. thats question indeed. this bug is mysterious and i can reproduce it unreliably on one older notebook i'm sitting now on (ATI radeon, linux closed source drivers) in ordinary case: \use_qimage false scrolling has 72% X - 22% lyx (of cpu time) \use_qimage true scrolling has 48% - 48% and feels somewhat slower which unfortunately shows that speed up might happen on nvidia while it slow down the thing at other system. secondly - up to now i was able to trigger the case of 97% X - 2% lyx only with \use_qimage false. in this case lyx is almost unusable and it seems i need already running another lyx instance in system to trigger it. whats really funny is that it seems that i'm able to repeat it quite more reliably in screnario first instance is \use_qimage true and second false. sometimes it doesn't happen in this scenario and it never happened (up to now) vice versa in false-true scenario. dont ask me why this should matter... so there is some chance the worst case scenario is gone in trunk. pavel
Re: Report (was: Qt: was Slow scrolling)
Pavel Sanda wrote: whats really funny is that it seems that i'm able to repeat it quite more reliably in screnario first instance is \use_qimage true and second false. sometimes it doesn't happen in this scenario and it never happened (up to now) vice versa in false-true scenario. dont ask me why this should matter... and whats interesting its buffer dependent as someone reported few days later. the worst scenario happens with user guide, when i open introduction, this issue disappears. so i switched off change tracking in user guide and the slowness is gone :) when i switch on tracking on introduction the problem is not there. hmm maybe the problem is with the content of user guide? no, when i delete all except first two pages and accept CT (only text no special insets remain) the problem is still there. it also doesn't explain why such CT thing appears only in random instances of lyx. and i did not take any substances today... pavel
Re: Report (was: Qt: was Slow scrolling)
Pavel Sanda wrote: hmm maybe the problem is with the content of user guide? no, when i delete all except first two pages and accept CT (only text no special insets remain) the problem is still there. one more observation: when more manuals are opened (with CT) i'm able to see slowness always only in single tab, the others are unaffected, moreover i can switch affected tab (so it really does not matter of the contents).
Report (was: Qt: was Slow scrolling)
Jean-Marc Lasgouttes wrote: > Le 05/01/2012 02:40, André Pönitz a écrit : >> The main performance problems I have seesn so far are due to an abuse of >> the toolkit, not caused _by_ the toolkit (except for the remote raster please... there were many cases we have no clue where the problem is. it can be lyx, qt, X, card drivers. to summarize the whole thing by saying that all is abuse of qt smells like problem with your affiliation ;) >> painter problem perhaps). Just start at RowPainter::paintChars() and >> walk down through all the mess _before_ it actually hits Qt's drawText() >> It is slow? You bet. > > The question is whether the "Xorg takes 90% cpu" complaints will go away > with Abdel new patch. thats question indeed. this bug is mysterious and i can reproduce it unreliably on one older notebook i'm sitting now on (ATI radeon, linux closed source drivers) in ordinary case: \use_qimage false scrolling has 72% X - 22% lyx (of cpu time) \use_qimage true scrolling has 48% - 48% and feels somewhat slower which unfortunately shows that speed up might happen on nvidia while it slow down the thing at other system. secondly - up to now i was able to trigger the case of 97% X - 2% lyx only with \use_qimage false. in this case lyx is almost unusable and it seems i need already running another lyx instance in system to trigger it. whats really funny is that it seems that i'm able to repeat it quite more reliably in screnario first instance is \use_qimage true and second false. sometimes it doesn't happen in this scenario and it never happened (up to now) vice versa in false->true scenario. dont ask me why this should matter... so there is some chance the worst case scenario is gone in trunk. pavel
Re: Report (was: Qt: was Slow scrolling)
Pavel Sanda wrote: > whats really funny is that it seems that i'm able to repeat it quite more > reliably > in screnario first instance is \use_qimage true and second false. > sometimes it doesn't happen in this scenario and it never happened (up to now) > vice versa in false->true scenario. dont ask me why this should matter... and whats interesting its buffer dependent as someone reported few days later. the worst scenario happens with user guide, when i open introduction, this issue disappears. so i switched off change tracking in user guide and the slowness is gone :) when i switch on tracking on introduction the problem is not there. hmm maybe the problem is with the content of user guide? no, when i delete all except first two pages and accept CT (only text no special insets remain) the problem is still there. it also doesn't explain why such CT thing appears only in random instances of lyx. and i did not take any substances today... pavel
Re: Report (was: Qt: was Slow scrolling)
Pavel Sanda wrote: > hmm maybe the problem is with the content of user guide? no, when i delete > all except first two pages and accept CT (only text no special insets remain) > the problem is still there. one more observation: when more manuals are opened (with CT) i'm able to see slowness always only in single tab, the others are unaffected, moreover i can switch affected tab (so it really does not matter of the contents).
