multiple interfaces to the screen driver plugin

[Dzha]

I am porting a reading app to an arm-based low refresh rate e-paper device. There is an existing Qt screen driver plugin already had been developed for this platform. A class derived from QLinuxFbScreen provides the screen update services.There are several views implemented in the app and there is a class that eventually calls repaint() and does the drawing inside the paintEvent().

I have a problem with the refresh on this device. All e-paper screens produce artifacts, so they have to do a special full screen refresh to avoid them. I only want to do this kind of refresh when the full page has been turned in the app. I want to do partial refresh if a hyperlink was highlighted or a small dialog box has been displayed.
So, do I need to invent fullRepaint() and fullPaintEvent() (by analogy to repaint/paintEvent), derive from QLinuxFbScreen and have a special blit for full refresh? Is there a simple more elegant way?

I have also posted this questions in another forum, but did not receive any replies so far.

[high_flyer]

(by analogy to repaint/paintEvent)
You probably mean repaint()/update().
(since repaint() triggers a paintEvent)

The question is, how the paintEvent() is implemented for this device - that is, how the region to be repainted is calculated.
Since you are dealing with Qt objects, which I assumer are QWidget descendants, then you might try using update(const QRect & rect ); or update(const QRegion & rgn ); and the repaint() equivalents.
With those you can specify the region to be updated.

[Dzha]

You probably mean repaint()/update().
(since repaint() triggers a paintEvent).

I meant a pair, a new repaint and a new paintEvent. So if I will call fullRepaint then it will trigger fullPaintEvent, which in turn will trigger a new fullBlit function in the driver plugin which will call a different low level ioctl in order to do a special refresh of the screen.



The question is, how the paintEvent() is implemented for this device - that is, how the region to be repainted is calculated.
Since you are dealing with Qt objects, which I assumer are QWidget descendants, then you might try using update(const QRect & rect ); or update(const QRegion & rgn ); and the repaint() equivalents.
With those you can specify the region to be updated.

Well, if I would use repaint() or any flavour of update() it will in the end call blit on the driver side wich will call a low level partial update routine from the driver.

In other words I need two different types of repaint to be mapped to two different types of blit in the driver, so my app will trigger the one that is required.

Yes, my app is QWidget based, but drawing from the the paintEvent will be passed to the driver's blit function that calls partial refresh. I do not have any criteria on how to trigger the full refresh in the driver itslelf, because the trigger for it is the user action -> page turned. I was thinking of checking the size of the rect being updated and if it is large enough then trigger full refresh, but it is unreliable.

Currently I use QPainter for drawing from the paintEvent. Is it possible to somehow redirect QPainter into a different low level routine?

Hmm, stumbled upon QPaintEngine class, shouldn't I think of re-implementing it?
It seams I do not need to change anythng on a widget side, but maybe derive from QPainter. implement a new method similar to drawPixmap which will use the new class derived from QPaintEngine? I think my head is starting to boil at this point :).