Apache OpenOffice (AOO) Bugzilla – Issue 72754
help content paints garbage in some topics
Last modified: 2007-02-05 13:32:14 UTC
- open a new text document - press F1, so the help component opens - on the "Find" page in the help component, enter "java start parameters" and press enter - double click the entry "Start Parameters" in the search results list => the topic "Java Start Parameters" is displayed in the right pane => there are painting errors - in particular black blocks - on the right hand side of the content pane. Repainting the window (e.g. minimizing and restoring it) solves the problem.
That's a regression in m194 (probably CWS aw024), since it does not happen in m193.
According to http://www.openoffice.org/scdocs/ddIssues_EnterModify.html#priority, this should probably be a P2.
AW: Needt to build incompatible due to #i72889#, looking forward...
AW: Debugging, all encapsulations of Begin/EndDRawLayers() works well. AW: When forcing the view (which is constructed every time a help is displayed) to not use overlay, the effect is gone. This hints to problems when restoring the content from the overlay buffer. AW: Indeed, the overlay buffer is not complete. This means that in Help and SW/Web, not all paints to the window are encapsulated by Begin/EndDrawLayers() calls yet. AW: One possible fix would be to disable overlay for WitrerWeb in help, but this would only avoid the symptoms. It is necessary to identify the Paints() which are made to the WIndow without DrawingLayer control. AW: How to find those paints? Getting vcl with debug, seem to be text paints...
AW: Added code to SwViewImp::MakeDrawView() to correctly init the overlay
AW: Added code to paint region for repaint before repaint and to paint region which gets saved to overlay buffer. AW: Problem found: In ViewShell::ImplEndAction() there is code which makes the whole redraw redirecting it to a temporary VDev. Redirecting starts with pOut = pVout; and ends with pOut = pOld; In-between, PaintDesktop and pLayout->Paint try to use Begin/EndDrawLayres to do their jobs. This already restores overlay and rescues stuff that is not yet painted. AW: This needs thorough thinking and discussion how to fix and interferes with other VDev buffering errors from SW already in aw039...
AW: Okay, i have now implemented a new DLPrePaint2/DLPostPaint2 which uses a counter to avoid multiple calls and a OutDev pointer to remember the OutDev for BeginDrawLayer call to give same to EndDrawLayer. When encapsulating all spaces where paints are done, all should work. A VDev paint e.g. is then prepared with DLPrePaint2 BEFORE the pOut in the SW drawView is changed, and ended after it. Thus, the copying in of the VDev represents the paint itself, the prep of the VDev content will work using temporary stuff. AW: Grepped for 'new*VirtualDevice' in SW, found some more places to secure, secured secured where useful. Added code to disable Overlav (SetBufferedOverlayAllowed(false)) in SwViewImp::MakeDrawView() when document is read-only. AW: All in all the VDev paints - which are used to avoid filcker - can be avoided by using the BufferedOutput feature of the DrawingLayer in the future. This would require new versions of BeginDrawLayer/EndDrawLayer which will return a SdrPaintWindow which allows access to the buffer itself as OutDev. The big advantage here is that the VDev willbe the same size as the DL view and thus same MapMode -> the buffered paint will always be the same as in the window. AW: Tested, checking in...
AW: Solved so far, but i will make some tests for the mentioned BufferedOutput...
AW: Okay, works. Experiments will go to next tasks. Closing this one.
AW->FS: please review, install sets are all ready
verified in CWS aw039
*** Issue 73659 has been marked as a duplicate of this issue. ***
closing ancient issues