Opened 10 years ago

Closed 10 years ago

#163 closed defect (fixed)

Screen corrupted when using QT_PM_DIVE

Reported by: KO Myung-Hun Owned by:
Priority: major Milestone: Qt Enhanced
Component: QtGui Version: 4.6.2
Severity: medium Keywords:



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.

Change History (12)

comment:1 Changed 10 years ago by 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.

comment:2 Changed 10 years ago by 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

comment:3 Changed 10 years ago by Dmitry A. Kuminov

Yes, please. r743 may fix this problem.

comment:4 Changed 10 years ago by KO Myung-Hun

Unfortunately, I reported this problem after testing with r744.

comment:5 Changed 10 years ago by 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).

comment:6 Changed 10 years ago by 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.

comment:7 Changed 10 years ago by 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.

comment:8 Changed 10 years ago by Dmitry A. Kuminov

Resolution: fixed
Status: newclosed

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.

comment:9 Changed 10 years ago by Dmitry A. Kuminov

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

comment:10 Changed 10 years ago by rudi

Resolution: fixed
Status: closedreopened

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) ?

comment:11 Changed 10 years ago by 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).

comment:12 Changed 10 years ago by Dmitry A. Kuminov

Resolution: fixed
Status: reopenedclosed

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

Note: See TracTickets for help on using tickets.