https://issues.apache.org/ooo/show_bug.cgi?id=122753

Armin Le Grand <[email protected]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|CONFIRMED                   |ACCEPTED
           Assignee|[email protected] |[email protected]
                   |g                           |
            Summary|Rotation of pictures gives  |Copy/Paste-as-Bitmap with
                   |damaged image               |GraphicObjects may show
                   |                            |wrong graphic

--- Comment #17 from Armin Le Grand <[email protected]> ---
ALG: @rgb: Thanks for the extra issue, thus I will adapt title of this one.

What happens is the following:
- CTRL-C clones the selection to a new model
- Paste-special/as Bitmap creates a Bitmap based on that cloned content

In the meantime the content of the cloned GraphicObject may have been streamed
out. The 'mechanism to get the primitives and convert to a BitmapEx' (a) will
create the replacement visualization that will be seen, the same as if a
GraphicObject is swapped out and fast scrolling temporarily shows this.

I changed (a) in r1432130 to directly use primitives, described in task
#121609#, to get a better quality for tiled bitmaps, comitted at 2013-01-11.
Thus, regression is correct. That change is not wrong since it uses
getViewIndependentPrimitive2DSequence at the ViewContact of the cloned
GraphicObject. As the name says this should return a view-independent
visualization, thus an evtl. streamed out graphic *should* be loaded.

Thus, the correct fix would be to change
ViewContactOfGraphic::createViewIndependentPrimitive2DSequence() to always
swap-in the needed graphic and to adapt
ViewObjectContactOfGraphic::createPrimitive2DSequence to do the view-dependent
part (as is intended). This fix is complicated and not safe enough for now.

A quick and safe workaround would be in SdrExchangeView::GetMarkedObjBitmapEx
to not just get the primitives from SdrObjects, but - if it's a SdrGrafObj -
first call SdrGrafObj::ForceSwapIn() at it.

The error itself is not always reproducible (I get it at maybe 15% of my tries)
and paste-special/as-Bitmap is not the joe-user-way. Thus, I do not think that
this should stop the AOO4.0...

Testing the proposed QuickFix...

P.S.: I could up to now not reproduce the corruption of the bitmap at rotation
time.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.

Reply via email to