Hello, Items specific to the Qt widget set.

Today I've spent some time to investigate how painting on QAbstractScrollArea should be done.

When we assigning viewport to scroll area (I dontk now actually why are we doing that if scroll area already create its own viewport on Init) that viewport reinstalled our event filter with its own and pass event to protected method of QAbstractScrollArea.

Here is definition of this method:
virtual bool viewportEvent ( QEvent * event )

So at moment we are doing all our painting on scroll area instead of viewport :)

We can ofcource install our event filter after qt installed its own filter for viewport, but I dont think such way things should be done (in my eyes this is hack).

Den, can you add that viewportEvent to QAbstractScrollArea?

I am trying to find reason of slow SynEdit painting. And I cannot find it. According to docs we are doing our painting in right way. But caret repainting takes 30%-50% cpu (depends on cpu) on big texts. I dont think that viewportEvent help us too much, but maybe then we can use QGraphicsView instead of QAbstractScrollArea for TCustomControl.

Related question is why update of QAbstractScrollArea calls not only paintEvent of that scroll area but also paintEvents of parent widgets?

well,it's possible. I've written that code and viewport is there for the same reason as H & V scrollbars are. I couldn't get an LCL handle from those widgets without reimplementation via TQtWidget & TQtScrollBar. Qt interface is not implemented like others (or like Qt2), with simple widget and scrollbars added by hand (it was first implementation but have a lot of problems).It's better if we can use qt classes for such things, like QAbstractScrollArea. I'm sure that Den will try to add viewportEvent() inside so we'll see the result.Only thing we didn't try about paintings on scrollarea is to paint viewport and area separatelly.