I’ve done some more debugging and I believe I’ve found the Qt code that turns 
the background black or white.
Om macos (and probably also on windows) Qt uses a QBackingStore for painting. I 
couldn’t find a QPlatformBackingStore for linux so I assume the implementation 
is different on linux, which would explain the different behaviour.

When issuing an viewport()->update() the region (the complete viewport if no 
smaller area is specified) is marked as dirty and at paint time is then 
repainted, via QWidgetBackingStore::doSync().
In QRasterBackingStore::beginPaint() the region is initially filled with a 
color Qt::transparent which has alpha=r=g=b=0 which will leave the screen black 
if not overwritten.

When WA_OpaquePaintEvent is not set this is followed by a paintBackground() 
call which fills the region with the autoFillBrush-color which has all ones. 
This will leave the screen white if not overwritten.

Depending on the update_strategy_ only a part of the screen is overwritten by 
lyx, leaving the rest black or white.
I assume that in the tests I’ve described previously all actions restoring the 
normal view somehow trigger a FullScreenUpdate.

pdv

> On 12 Oct 2017, at 21:30, Jean-Marc Lasgouttes <[email protected]> wrote:
> 
> Le 08/10/2017 à 18:57, pdv a écrit :
>> The new code contains twice a viewport()->update() without specification of 
>> a rectangle. Since > Qt normally erases the widget's area before the 
>> paintEvent() call
>> I guess that the whole viewport is erased. Subsequently only part of it is 
>> redrawn except for the case FullScreenUpdate and in that case there is no 
>> problem.
> 
> Actually, we use
>       viewport()->setAttribute(Qt::WA_OpaquePaintEvent);
> to ask Qt not to overwrite it. It seems to work on Linux.
> 
> Please feel free to look at the code and docs (QWidget and 
> QAbstractScrollArea) and tell us what I may have missed. I just saw that we 
> should override viewportEvent() instead of event(), but I am not sure that it 
> would make a difference.
> 
> Can you compile master? Do you see the issue?
> 
> JMarc


Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to