zaphod.b
14th July 2009, 16:29
Hi all,
This is in a way the follow-up to this thread (http://www.qtcentre.org/forum/f-qt-programming-2/t-qscrollarea-vs-qabstractscrollarea-22257.html/?highlight=QScrollArea). Please consider the code fragment in the starting post thereabout. There are some minor changes, and MyWrapper inherits QAbstractScrollArea now, but basically it's the same.
My problem is: I can't make MyWrapper paint on its viewport() properly due to synchronization problems with Foo::update().
These are the facts:
All painting has to take place within MyWrapper::paintEvent().
All rendering is triggered by calling (3rd-party class method) Foo::update(). This starts a thread which I have no access to.
Hooks (callbacks) can be registered with Foo that are then called to indicate start/finish of the rendering. As these then belong to render thread, they cannot repaint MyWrapper directly. Instead they need to go via main event loop by calling MyWrapper::update() or posting a custom event.
In MyWrapper::paintEvent() handler, depending on event origin and Foo's state, either the rendering must be triggered, or the results painted. Mind that before paintEvent() is entered the widget is usually erased by Qt.
Whichever way of signalling from within the hook is used: Eventually a paint event need be sent. This may interfere with paint events sent by the window system and is where the synchronization problem arises.
So, as I currently see it, the problem is basically to distinguish between paint events that originate from Foo::hook() and those that don't.
I thought of subclassing QPaintEvent, but as events do not inherit QObject, there is no way of identifying these custom paint events within MyWrapper::paintEvent().
As wysota advised in the other thread, I do manage a QImage class variable MyWrapper::_img that is initialized by a custom event handler from the finish hook, and uninitialized from the start hook. However, this alone does not suffice as the hooks need to signal via the main event loop and thus asynchronously, leaving the state of _img somewhat uncertain.
I tried a gazillion things, so I may well not see the wood for the trees anymore. Is there an obvious solution after all? Any help appreciated very much.
This is in a way the follow-up to this thread (http://www.qtcentre.org/forum/f-qt-programming-2/t-qscrollarea-vs-qabstractscrollarea-22257.html/?highlight=QScrollArea). Please consider the code fragment in the starting post thereabout. There are some minor changes, and MyWrapper inherits QAbstractScrollArea now, but basically it's the same.
My problem is: I can't make MyWrapper paint on its viewport() properly due to synchronization problems with Foo::update().
These are the facts:
All painting has to take place within MyWrapper::paintEvent().
All rendering is triggered by calling (3rd-party class method) Foo::update(). This starts a thread which I have no access to.
Hooks (callbacks) can be registered with Foo that are then called to indicate start/finish of the rendering. As these then belong to render thread, they cannot repaint MyWrapper directly. Instead they need to go via main event loop by calling MyWrapper::update() or posting a custom event.
In MyWrapper::paintEvent() handler, depending on event origin and Foo's state, either the rendering must be triggered, or the results painted. Mind that before paintEvent() is entered the widget is usually erased by Qt.
Whichever way of signalling from within the hook is used: Eventually a paint event need be sent. This may interfere with paint events sent by the window system and is where the synchronization problem arises.
So, as I currently see it, the problem is basically to distinguish between paint events that originate from Foo::hook() and those that don't.
I thought of subclassing QPaintEvent, but as events do not inherit QObject, there is no way of identifying these custom paint events within MyWrapper::paintEvent().
As wysota advised in the other thread, I do manage a QImage class variable MyWrapper::_img that is initialized by a custom event handler from the finish hook, and uninitialized from the start hook. However, this alone does not suffice as the hooks need to signal via the main event loop and thus asynchronously, leaving the state of _img somewhat uncertain.
I tried a gazillion things, so I may well not see the wood for the trees anymore. Is there an obvious solution after all? Any help appreciated very much.