Different behaviour of backingStore between macos and linux.

pdv_

I have a question on the behaviour of the Qt-backingStore on macos.
When issuing viewport()->update() without specifying a rectangle an update of the rect of the widget is issued. It looks like in that case Qt expects a full redraw of the widget. If the widget only partially redraws its content, then the rest is painted black (Qt-5.9.2) or becomes transparent (Qt-5.10). If true it means that for a partial redraw one must always specify the correct rect in the update(rect) call. However this seems not to be a problem on linux.
Which of the 2 behaviours is the intended one?

This behaviour was not present in Qt-5.4.1 and can be traced back to the introduction of QCocoaBackingStore::beginPaint() where the background is indeed filled with the QColor::transparent.
The commit-message for this change reads: "Clear backingstore for windows with alpha channel. Fixes painting artifacts in translucent windows.”

VRonin

@pdv_ said in Different behaviour of backingStore between macos and linux.:

Which of the 2 behaviours is the intended one?

This is my opinion, not the absolute truth

I'd say "for a partial redraw one must always specify the correct rect in the update(rect) call" is the intended behaviour, and the fact that it works in linux is just a result of undefined behaviour

VRonin

Being a little more scientific, from http://doc.qt.io/qt-5/qwidget.html#update

Qt normally erases the widget's area before the paintEvent() call.

JMarc

@VRonin actually in the case we are interested in Qt::WA_OpaquePaintEvent is set. The docs says that Qt can take this opportunity to leave the backing store alone, but it does not on OSX (we did not have the opportunity to test windows yet).

It looks like the changed mentioned by pdv was done for the benefit of translucent windows, but it should not trigger for plain old opaque windows, IMO.

PS: the context is LyX, for which we have built our own hand-made editor.

VRonin

1st of all, thanks for your effort, I use LyX myself.

The doc says:

this indicates that the widget will paint over its entire area with opaque colors. The widget's area will initially be uninitialized

set the widget's Qt::WA_OpaquePaintEvent, avoiding any unnecessary overhead associated with repainting the widget's background

Meaning it is saying it won't bother painting a background but it's not committing to leaving the old painted background in place so I still think you are relying on undefined behaviour.

On the other hand, I think this also impacts the performance of widgets with Qt::WA_OpaquePaintEvent on macOS so it is probably worth highlighting it with a bug report and/or an email on the mailing list