Assistant not drawing correctly on startup (direct frame bufffer mode only)

[rudi]

When using direct frame buffer access, QtAssistant? doesn't paint it's window correctly right after startup. The window must be manually resized in order to correct this. I observe this behavior only with Assistant. Linguist and Designer start up as expected.

[rudi]

I think, I've found the problem. For some reason we run into a situation, where the height of the window changes between the calls to QPMDiveWindowSurfaceFB::doFlush while d->vrnDirty is false. Thus, the visible rects are not updated even though they should. My workaround is to store the height of the window at the time the rects were queried (
QPMDiveWindowSurface::adjustSetup()) into a newly added member of QPMDiveWindowSurfacePrivate. In QPMDiveWindowSurfaceFB::doFlush() I compare the actual window size to the size at the time the rects were retrieved. If it differs, I set d->vrnDirty to true forcing QPMDiveWindowSurface::adjustSetup() to do the right thing.

[rudi]

Modifications for qwindowsurface_pm.cpp (previous unzipped upload got corrupted somwhow)

[Dmitry A. Kuminov]

Should be fixed in r743, please check.

PS. The .diff file in .zip is still wrong -- it contains 0xFF instead of spaces in many places.

[rudi]

O.K. r743 works for me. There are some other drawing issues, but they are difficult to reproduce. Still investigating...

Two minor points: In qwindowsurface_pm.cpp, line 906 we call DiveClose? when the creation of a new surface instance failes. Probably we should do this only in BLIT mode, not when using a shared DIVE instance. The second thing is that in line 605 we could use a "const" parameter:

foreach(const QPMDiveWindowSurfacePrivate::FlushArgs? &args, d->pending)

Regarding to the diff: I was using cut 'n paste from a window of my (a little bit polished) OS/2 version of eSVN, based on Qt3.

[Dmitry A. Kuminov]

Corrected the DevClose? thing (however I doubt that this code will be ever executed :) (and we/Nokia don't check for all failed new allocations anyway so what I write in such cases basically depends on my mood...).

The FlushArgs? thing is really minor (the structure is very small) but I corrected it too as it's a good practice; the essential part here is & (reference) though, not const -- it's the former that avoids creating a local copy, not the latter (which is only a semantic compile-time restriction in this particular case).

I think that we should create new defects for other repaint problems as the one described here has been fixed.