Created attachment 178433 [details] reproducer slideshow from mso powerpoint Steps to reproduce: 1. Open attached pptx document in Impress 2. Observe the shapes 3. Start slideshow -> Shapes appear stretched in the slideshow, unlike how they appeared in the edit mode. Version: 7.4.0.0.alpha0+ / LibreOffice Community Build ID: 8b327cd86d71d71d2f5f883321e5d53e3b42ed4e CPU threads: 4; OS: Linux 5.16; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
Created attachment 178435 [details] Before regression LO slideshow
Created attachment 178436 [details] After regression LO slideshow
Regression introduced by: https://cgit.freedesktop.org/libreoffice/core/commit/?id=4d535c4f867d86d40786788e5e5c9fd061a65673 author Armin Le Grand (Allotropia) <Armin.Le.Grand@me.com> 2022-01-31 19:44:19 +0100 committer Armin Le Grand <Armin.Le.Grand@me.com> 2022-02-02 09:43:10 +0100 commit 4d535c4f867d86d40786788e5e5c9fd061a65673 (patch) tree 9611377bf20a0d9ac46ffc1101f769ae0e1f7ac3 parent 60a1f07049a817d4d3d7beb6c9b9da2571e2463b (diff) tdf#126319 Corrected bitmap creation from metafile Bisected with: bibisect-linux64-7.4 Adding cc: to Armin Le Grand
Confirm with Version: 7.4.0.0.alpha0+ / LibreOffice Community Build ID: 0723b41bed9bb4ad50d2993744a60177966d1a21 CPU threads: 4; OS: Linux 5.13; UI render: default; VCL: gtk3 Locale: cs-CZ (cs_CZ.UTF-8); UI: en-US Calc: threaded Jumbo
Seems as if something is wrong with the size of the Metafile that gets created in-between. Selecting one of the objects and using convert/to_metafile in the context menu creates a correct metafile, bit it's frame is too big - same too big as the shape is later, stretched vertically.
Tried to check what ConvertToMetafile does for that objects, but 2nd time converting them does not create that too big metafile again - after undo. Very strange & makes things difficult...
Looks like SdrExchangeView::GetMarkedObjMetaFile gets that wrong stretched BoundRect from 1st call to GetMarkedObjBoundRect() - very strange. Together with that no longer happening after doing once & UNDO it smells more like BoundRect being wrong after import. Indeed, after having all converted once & then slideshow display is correct. Weren't there some 'optimizations' recently to not broadcast too much after import - to avoid too much recalculations & broadcastings...?
Indeed, adding ::std::vector< SdrObject* > aSdrObjects(GetMarkedObjects()); for(auto* pCand : aSdrObjects) pCand->SetBoundRectDirty(); to SdrExchangeView::GetMarkedObjMetaFile and thus forcing update of he BoundRects corrects that error when 1st converting to Metafile. This is proof that the BoundRects are *wrong* after import. Thus my change is not a regression, but uncovers another error.
There definitely *was* a mechanism to do some cleanups/refreshes after import/load, I checked SdrModel::setLock that does ReformatAllEdgeObjects. Releasing the lock at the SdrModel is used to act at end of import. I am not sure how that was formally done for invalidating the BoundRects of SdrObjects, but it seems definitely no longer to be done. Trying to find how that was done formally (probably some broadcast...)
There are re-calculations of RecalcBoundRect() after lock is freed. Nonetheless, the correction form comment 8 works for context menu convert/to metafile as correction, so these seem to be initially wrong calculated (?) A slideshow start we can check at DrawShape::DrawShape in slideshow/source/engine/shapes/drawshape.cxx. In member initilaization there is maBounds( getAPIShapeBounds( xShape ) ), which uses GetCurrentBoundRect() over UNO API and there is mpCurrMtf = getMetaFile(uno::Reference<lang::XComponent>(xShape, uno::UNO_QUERY), xContainingPage, mnCurrMtfLoadFlags, mxComponentContext ); below that. The mpCurrMtf PrefSize (created using the corected GraphicExporter::GetGraphic mentioned as regression commit) is correct, while maBounds (from GetCurrentBoundRect()) is not. Trying to make a useful conclusion from this...
Created a version without the change in discussion. The context menu convert/to metafile creates the same error, so the BoundRect is already wrong in that version. But he Presentation works - have to check why, AFAIK GraphicExporter::GetGraphic (where the change is) is not used by Presentation preparations...?
(In reply to Armin Le Grand from comment #11) > Created a version without the change in discussion. The context menu > convert/to metafile creates the same error, so the BoundRect is already > wrong in that version. But he Presentation works - have to check why, AFAIK > GraphicExporter::GetGraphic (where the change is) is not used by > Presentation preparations...? I just checked the error with the convert/to metafile case, can confirm that is changing the shapes from square to rectangle shape at least since 3.5.0 - this is not a new issue by any means.
(In reply to Gabor Kelemen (allotropia) from comment #12) > this is not a new issue by any means. I read this aa "not a regression" but it's marked so, please clarify.
(In reply to Armin Le Grand from comment #8) > Thus my change is not a regression, but uncovers another error. Bug #150402 was bisected to the same commit and appears quite different from the outside? Maybe that's worth pursuing, Armin?
This is looking good after https://git.libreoffice.org/core/+/1b0ff1c166211b34370f53995ae9fb3f8eed182e%5E%21 author Armin Le Grand (allotropia) <armin.le.grand.extern@allotropia.de> Mon Sep 19 11:48:20 2022 +0200 committer Armin Le Grand <Armin.Le.Grand@me.com> Mon Sep 19 16:24:46 2022 +0200 tdf#150402 Correct wrong Bound of Shape in Slideshow *** This bug has been marked as a duplicate of bug 150402 ***