Created attachment 53871 [details]
Paint error after maximizing

.

This bug has nothing to do with that wonderful CWS aquabmpfixes01, because it also happens on plain 
DEV300_m12/13/14 builds on unxmacxi/wntmsci12/unxlngi6 platforms... reassigning to the chart 
project

adjusting the issue summary

This error is not chart specific. It happens with any OLE object and also with
plain graphics files. Just drag a PNG into Calc and maximize the app window to
see the paint error. Note that I cannot reproduce this problem on any other
platform, it is Mac specific.
To me this looks like a problem when copying/blitting bitmaps around.
HDU, please have a look. 

The aqua-specific clipping problem is already being addressed in issue 89828, so what remains looks like 
a serious drawing layer problem with OLE objects:
1. open Writer/Impress/Draw
2. create a simple chart
3. click into the chart to make it editable
4. maximize the app window
=> severe paint errors are visible (the chart is painted twice!)

AW: Only happens when maximizing the window with activated OLE, not when
starting maximized and going back to old window position. Workaround is to once
deactivate and reactivate OLE.
That two charts are shown is because the DrawingLayer paints it's OLE object and
the activated OLE is visible in a VCL-Window. When both are not aligned (same
positions), both are visible. The misaligned one is the activated OLE. Need to
find out who is positioning (and maybe resizing) activated OLEs. Changing
Summary accordingly.

AW: Just checked that the same happens in SW, but not in calc. Obviously, there
has vener been code in SD or in SW to position activated OLEs on window resize.
Maybe NN knows more about it since it works in SC.
AW->MAV: I hope You may know more about e.g. if an activated OLE is a VCL-Window
or not and who should reposition it, also maybe MBA knows more about it (i add
him to the task). The question is who should do that repositioning (or is doing
in tin SC). I guess it's something for the applications SD and SW.

The unexpected move of the object does not happen in Calc only because the Calc
does not change the document page placement after maximizing.

In other words, when the document is maximized, the container part of the
embedded object control gets no notification regarding object move. So the
window of the active object has just the same position relative to the document
window. In Calc this position is correct by luck, but in Writer and Draw the
document page might be moved ( centered ), so the repositioning is required.

Thus it is no problem of Writer and Draw, it is just generally missing move of
the embedded object window, that luckily does not affect the functionality in Calc.

target 3.x

target changed to 3.1

There are not enough resources to get it for OOo3.1, changing the target.

Issue 76401 may be related.

*** Issue 76401 has been marked as a duplicate of this issue. ***

The scenario from issue 76401 should be tested after the bug is fixed.

mav->iha: As far as I remember the problem described here was reproducible for
writer as well. Only Calc has worked ( since its visual area position does not
really change in the scenarios ). The impress has of course more scenarios where
the visual area changes, but the writer is affected as well.

iha->mav: The window resize in impress from issue 76401 is not triggered by the
user. The user scenario to edit an OLE object within impress is much more common
than maximizing a window while in edit mode I think. So I found it important to
add that more problematic scenario to the summary.
But while reading more through this issue I am quite irritated about its
content. It was reported for Calc and later it is stated that it does occur in
all applications but not in Calc? It seems that something has been mixed here.
Further I cannot reproduce the mentioned wrong placement within writer nor calc
with a current Office version on windows - not with dev30m50 and not with OOo
3.1. So either this issue is fixed or it is about a special paint problem on
mac. In both cases issue 76401 is not a duplicate as it does occur on windows
with dev300m50.

Further research revealed: The positioning problem within writer does still
occur in dev300m31, but does not occur in dev300m33. So somewhere inbetween it
was fixed.

mav->iha: You are right, the problem is not reproducible any more. And the
reason is that the applications preserve the topleft corner of the visual area
currently ( the application is not centered any more ). So it looks like the
problem was workarounded.

At the beginning the problem has mixed problems with embedded object and
embedded pictures. Additionally the part of scenario was already fixed, so when
I have got the issue it was already only about all the applications except Calc.
And the original reason was the same as the reason for issue 76401 ( at least as
it looks currently for me ), change of the container visual area position was
not notified to the active object.

I completely agree that the issue 76401 should not be marked as duplicate of
this issue in this case. Moreover I will close this issue as non-reproducible then.

mav->mru: Please verify that the issue is no more reproducible in all the OOo
container applications.

Hm, interesting. In writer the issue looks indeed to be explicitly fixed. the
visual area is changed there and the object gets notification now.

confirm MAV's finding in DEV300m51 (checked with unxmacxi.pro build).