Qt 5.5.1 + QwtPlotDirectPainter = a solution to the black plotting area on OS X?

[Uwe]

I must confess that I don't quite understand the reason for that filter since such an event filter will always return false in the case of a canvas, or am I missing something?

Starting with Qt4 it was not possible anymore ( beside for X11 graphics system, that is gone since Qt 5 ) to paint to a widget outside of a QWidget::paintEvent - because of how the Qt graphic stack is made. Of course this is the opposite of the idea of what QwtPlotDirectPainter is about. So this class is somehow doing things "against" how the Qt framework wants to have it.

So on platforms, where Qt::WA_PaintOutsidePaintEvent is not supported QwtPlotDirectPainter sends an paint event to itself, that is caught by a temporary event filter. The code in the event filter is then running in the paint event context Qt is expecting to be valid, when painting to a widget.

What your patch does is to disable the event filtering with the consequence, that the paint event goes in the normal event processing ( QwtPlotCanvas::paintEvent() ), where you run into a full repaint of the canvas. So the patch doesn't make too much sense as you would call canvas()->repaint() or probably QwtPlot::replot() for this.

Unfortunately I don't have a Mac myself, but I would guess, that the problem is related to incremental painting - not to where it happens. If this is the case I can imagine, that using QwtPlotDirectPainter::FullRepaint in combination with QwtPlotCanvas::BackingStore is the best option as you still paint incrementally ( to the backing store ), but the widget is always repainted in the context Qt is expecting it.

If you find out, that the problem is related to the fact, that rendering is done inside the event filter - not the paint event handler - you would at least have to implement some handling, that can identify the special type of paint event, where you simply have to draw some lines incrementally.

But maybe you find out more than "guessing", when debugging what i going on on your Mac.

Uwe

[agarny]

Thanks a lot for the clarification, Uwe. I now understand the reasoning behind your use of a temporary event filter.

Ok, here is what I have done next...

I tried to use QwtPlotDirectPainter::FullRepaint in combination with QwtPlotCanvas::BackingStore, but although it's working fine on my development machine (OS X 10.11), it's not working as I would expect on OS X 10.8-10.10. Basically, if I try to plot 1,000,000 data points, then the plotting won't be smooth. Instead, I will get chunks of data points being plotted at once. So, it looks like I am getting some full repaints here and there.

Next, and following your explanations, I re-enabled the temporary event filter and, indeed, this results in QwtPlotDirectPainter::eventFilter() being called for QEvent::Paint. However, as previously mentioned, this results in the plotting area becoming black on OS X. To comment out the return true; in QwtPlotDirectPainter::eventFilter() obviously 'fixes' the problem, but on OS X 10.8-10.10, it results in the issue mentioned in my previous paragraph, not to mention that not returning true obviously defeats the purpose of your temporary event filter! So, I put back return true; and then noticed the CopyBackingStore attribute. I therefore set it to true in my application and it's now all working fine and as I would expect, be it on my development machine or on a vanilla OS X 10.8-10.10 machine. I understand that having BackingStore set to true means slightly more work (i.e. always copying the backing store to the painter), but I guess that what matters to me at this point is that I now have a solution that not only seems to be working fine and as expected, but also makes sense to me (as opposed to last time where I was disabling the temporary event filter without really knowing why).

In summary, thanks for putting me on the right track...

[Uwe]

I understand that having BackingStore set to true means slightly more work (i.e. always copying the backing store to the painter)

The price you have to pay for this mode varies from platform to platform - f.e when running remote desktops it might be significant. Maybe it's worth to spend some time on clipping, it can do miracles.

When adding a couple of points they often have a small bounding rectangle only. Using the canvas maps you can translate this rectangle into paint device coordinates and use it as clip region ( QwtPlotDirectPainter::setClipRegion ). Then only this parts of the pixmap will be copied to the graphics backend.

I once did this for a device running QWS on top of an unaccelerated frame buffer. Copying 10 x 10 x sizeof(RGBA) only made a huge difference compared to copying 800 x 600 x sizeof(RGBA).

Uwe

[agarny]

When adding a couple of points they often have a small bounding rectangle only. Using the canvas maps you can translate this rectangle into paint device coordinates and use it as clip region ( QwtPlotDirectPainter::setClipRegion ). Then only this parts of the pixmap will be copied to the graphics backend.

Thanks a lot for the suggestion, I am going to give QwtPlotDirectPainter::setClipRegion() a try.