Created attachment 143264 [details] Issue with 6.2 in back of 6.1 Insert a rectangle (or any other object) and use "Toggle Extrusion" from the drawing toolbar (View > Toolbars > Drawing). That results in a 3D-like object for 6.1 but not 6.2. Happens on Windows with Beta and on Linux with master from latest sources, and for Writer as well as Draw. Version: 6.2.0.0.alpha0+ Build ID: 683fa7b68673c8c6563ee493b8b5682bb6fd1b8a CPU threads: 8; OS: Linux 4.17; UI render: default; VCL: gtk3; Locale: en-US (en_US.UTF-8); Calc: group threaded
OK in Version: 6.2.0.0.alpha0+ (x64) Build ID: f7f2d03bd6f5aa5dcd0f7976b4a7f2db278c2f03 CPU threads: 8; OS: Windows 10.0; UI render: default; TinderBox: Win-x86_64@42, Branch:master, Time: 2018-05-25_05:00:28 Locale: de-DE (en_US); Calc: CL Broken in Version: 6.2.0.0.alpha0+ (x64) Build ID: 596820a5a3d9a12196b6bbcbfcb6d16ecd437962 CPU threads: 8; OS: Windows 10.0; UI render: default; Locale: en-US (en_US); Calc: CL In turn Fontwork is broken too.
Regression introduced by: author Armin Le Grand <Armin.Le.Grand@cib.de> 2018-04-16 22:34:50 +0200 committer Armin Le Grand <Armin.Le.Grand@cib.de> 2018-05-25 12:31:32 +0200 commit 4b4942224b550235da228655677b5c068a053254 (patch) tree a660a04a1f7a3eee910da780ece271d68942201d parent f8edef392245c292398a80f6a858ca19f32df9c3 (diff) SOSAW080: Derive SdrObjGroup from SdrObjList Bisected with: bibisect-linux64-6.2 Adding Cc: to Armin Le Grand
Strange - normal 3D (Draw objects, Chart, ...) works well. Probably something special with CustomShapes - they create their geometry using 'hidden' SdrObjects and these use groups/3DScenes.
Problem identified: In ViewContactOfSdrObjCustomShape::createViewIndependentPrimitive2DSequence the 'hidden/tooling' SdrObject hierarchy for emulating the CustomShape content is traversed using SdrObjListIter aIterator(*pSdrObjRepresentation); what creates a SdrObjListIter in mode DeepNoGroups. There the behaviour *has* changed: Old code used if ( dynamic_cast<const SdrObjGroup*>(&rObj) != nullptr ) to decide if it's a Group, while new code uses const SdrObjList* pChildren(rSdrObject.getChildrenOfSdrObject()); const bool bIsGroup(nullptr != pChildren); which is more correct due to E3dScene *having* children, too. Thus for the SDrObjecvt being a 3D scene: Old code -> only the E3dScene was added to the SdrObjListIter New code -> due to 'DeepNoGroups' the E3dScene gets *not* added, but the ExtrudeObject Problem is that this is - in principle - more correct. Ergo, the old code only worked due to an error - to handle E3dScene *not* as GroupObject. Have to think about how to fix that mess...
I also understand the 'yellow lines' visualized here - this is the fallback for 3D objects that someone tries to visualize outside of a 3DScene context...
Checked if iteration is needed at all, seems not to be the case. That would be a good solution. Checked with more complex CustomShapes (which are represented with more than one visualization-SdrObject) and compared with libreoffice-6-1, looks the same. Especially the 'smiley' is strange, the eyes are there but pretty much invisible (can be seen when rotating) - same as in libreoffice-6-1. This should be overhauled, it is just a bad visualization, but in a nother task.
Have written tdf#118795 for the bad visualization of 3D-CustomShapes
Armin Le Grand committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=ee71c3def71508d1fc3e110659c7ed7aa0ba2238 tdf#118498 Correct CustomShape 3D Visualization It will be available in 6.2.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
@Armin, should it be cherry-picked to 6-1 ?
@Xisco: Different mechanism, would need some extra work. Not sure about risk
(In reply to Armin Le Grand (CIB) from comment #10) > @Xisco: Different mechanism, would need some extra work. Not sure about risk Actually, the issue is not reproducible in Versión: 6.1.0.2 Id. de compilación: b3972dcf1284967612d5ee04fea9d15bcf0cc106 Subprocs. CPU: 1; SO: Windows 6.1; Repres. IU: predet.; Configuración regional: es-ES (es_ES); Calc: group threaded Sorry for the noise!!
Cherry-picked to 6-1 -> https://gerrit.libreoffice.org/#/c/61207/1
Armin Le Grand committed a patch related to this issue. It has been pushed to "libreoffice-6-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=316281cf1d888a4bac9f1e40e92c66405480249c&h=libreoffice-6-1 tdf#118498 Correct CustomShape 3D Visualization It will be available in 6.1.3. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Verified in Version: 6.1.3.0.0+ Build ID: 316281cf1d888a4bac9f1e40e92c66405480249c CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); Calc: group threaded