Screen corrupted when using QT_PM_DIVE

[KO Myung-Hun]

Hi/2.

When a window is resized in according to making a window inside it, the screen is corrupted.

QT_PM_NO_DIVE can prevent this corruption.

You can confirm using SMPlayer. The initial window of SMPlayer is corrupted if QT_PM_DIVE is set.

[Dmitry A. Kuminov]

Just to clarify, are you sure you tried the latest SVN version? We had a couple of related fixes after the 4.6.2 release.

[Silvan Scherrer]

i also had a user complaining about the same. after he added QT_PM_NO_DIVE it works.
This is also with a SNAP driver. so i have the feeling that on some SNAP systems only VESA is emulated. and that those also fail like the panorama only systems. this is with 4.6.2 GA. i would have to send him the latest qtgui4.dll to see if it latest svn helps

[Dmitry A. Kuminov]

Yes, please. r743 may fix this problem.

[KO Myung-Hun]

Unfortunately, I reported this problem after testing with r744.

[Dmitry A. Kuminov]

Okay, I see the corruption here with the latest SVN as well. The reason may be actually similar to what's in #161 -- AFAIR, SMPlayer uses the native child window (with its own HWND) for displaying the video and apparently this window doesn't get excluded when we paint everything else in the top-level window in DIVE mode. The only strange thing is that it should also happen in NO_DIVE mode as well but it doesn't (though this may work correctly due to the fact that most redraws happen using WM_PAINT in such case).

[rudi]

I think, I've found it:

Exchange lines 406 and 407 in qwindowsurface_pm.cpp so that wbr gets calculated on the already translated bounding rect.

Also, when we are there: In line 576, DiveSetupBlitter() does not need to be called when in frame buffer mode.

[Dmitry A. Kuminov]

I confirm that it fixes the problem though I really wonder why, as the logic in void QRasterWindowSurface::flush() is quite the opposite (wbr is calculated w/o taking the offset into account) and it works there too.

[Dmitry A. Kuminov]

Okay, I found the explanation and fixed the problem in r745. See the comments in this changeset for details. Rudi, sorry, I forgot to give you a credit in the commit message, so I want to thank you here for spotting the right place!

Re DiveSetupBlitter() at #576, QPMDiveWindowSurface::doFlush() is not called in FB mode, QPMDiveWindowSurfaceFB::doFlush() is.

[Dmitry A. Kuminov]

Ah it's the one in WM_VRNDISABLED actually; yes, removed in r746, thank you.

[rudi]

Hi Dmik,

I still have a problem with your explanation of the phenomenon and the "inDrag" code path. Please do a small test: Change QPMDiveWindowSurface::flush so that the inDrag code gets executed always. IMHO, it should then behave identical to QT_PM_NO_DIVE=1. However, if I run SMPLAYER, I get corruption again (now on top of the window). This was not present in my originally suggested fix.

BTW, do we need to check inDrag when using a hardware mouse pointer (QT_PM_DIVE=FB) ?

[Dmitry A. Kuminov]

Rudi, yes, there is a typo in the inDrag code path that I already spotted while double-checking my explanation yesterday (we should get HWND and HPS from widget, not from window(), of course -- i.e. be absolutely identical to the QT_BITMAP_MIRROR=3 code block when not using DIVE). I will commit the fix later (I'm now working on #161 and there is a mess in the sources ATM).

I don't have the hardware mouse pointer so I cannot check this. If you can and you confirm that it works (i.e. no corruption when doing DnD with the disabled inDrag block), I will change that. What makes me concern is that there is not only the mouse pointer while dragging, there is also a custom bitmap (that represents the dragged object) and I doubt that this custom bitmap is also drawn in the hardware pointer's layer even on the video cards that have it (this bitmap may be quite big -- any size, actually).

[Dmitry A. Kuminov]

r752 fixes this last issue and the inDrag code works well now.