Issue 72754 - help content paints garbage in some topics
Summary: help content paints garbage in some topics
Alias: None
Product: General
Classification: Code
Component: ui (show other issues)
Version: 680m194
Hardware: All All
: P2 Trivial (vote)
Target Milestone: OOo 2.2
Assignee: Frank Schönheit
QA Contact: issues@framework
Keywords: regression
: 73659 (view as issue list)
Depends on:
Reported: 2006-12-19 12:53 UTC by Frank Schönheit
Modified: 2007-02-05 13:32 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Note You need to log in before you can comment on or make changes to this issue.
Description Frank Schönheit 2006-12-19 12:53:06 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.
Comment 1 Frank Schönheit 2006-12-19 12:54:22 UTC
That's a regression in m194 (probably CWS aw024), since it does not happen in m193.
Comment 2 Frank Schönheit 2006-12-19 12:55:01 UTC
According to, this should
probably be a P2.
Comment 3 Armin Le Grand 2007-01-03 16:35:48 UTC
AW: Needt to build incompatible due to #i72889#, looking forward...
Comment 4 Armin Le Grand 2007-01-04 15:14:11 UTC
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...
Comment 5 Armin Le Grand 2007-01-04 16:40:34 UTC
AW: Added code to SwViewImp::MakeDrawView() to correctly init the overlay
Comment 6 Armin Le Grand 2007-01-04 16:47:15 UTC
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...
Comment 7 Armin Le Grand 2007-01-05 15:57:47 UTC
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...
Comment 8 Armin Le Grand 2007-01-08 09:56:53 UTC
AW: Solved so far, but i will make some tests for the mentioned BufferedOutput...
Comment 9 Armin Le Grand 2007-01-09 11:42:20 UTC
AW: Okay, works. Experiments will go to next tasks. Closing this one.
Comment 10 Armin Le Grand 2007-01-10 10:25:38 UTC
AW->FS: please review, install sets are all ready
Comment 11 Frank Schönheit 2007-01-10 14:29:40 UTC
verified in CWS aw039
Comment 12 Armin Le Grand 2007-01-19 14:57:18 UTC
*** Issue 73659 has been marked as a duplicate of this issue. ***
Comment 13 Mathias_Bauer 2007-02-05 13:32:14 UTC
closing ancient issues