3dboxes displaced on load (rev >= 10466)

[su_v]

3dboxes created with 0.48 e.g. after resizing the page or changing the page orientation load incorrectly in trunk (rev >= 10466).

Steps to reproduce:
1) launch Inkscape 0.48
2) change page orientation to 'Landscape'
3) draw 3dboxes, save and quit

4) launch current trunk
5) open just created file (or the attached sample)

Expected result:
Trunk renders file the same as 0.48.x (with attached sample file the 3 boxes are supposed to be within the page area)

Actual result:
On load the 3dboxes are positioned incorrectly, however executing a 'File > Revert' restores them to the same position as in Inkscape 0.48, and with revision >= 12532, it seems sufficient to select one of the 3dboxes to trigger an update (all boxes are repositioned immediately).

Reproduced with r12653 on Ubuntu 13.04 and r12654 on OS X 10.7.5.

Based on tests with archived builds (this goes back quite far into the history of current trunk):
- not reproduced with revision <= 10464,
- reproduced with revision >= 10466,
the regression seems originally related to revision 10466 (rename SPItem::i2d_affine to i2dt_affine):
<http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/10466>
The later change originates from the "C++ification of the SP tree"-merge in r12532:
<http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/12532>

[su_v (suv-lp)]

Attaching another file which exhibits the same behavior, even though AFAICT the layer group does not have a preserved 'transform' attribute (the file is the original version of the example used to illustrate bug #567858).

[jazzynico (jazzynico)]

Confirmed on Windows XP, Inkscape trunk revision 12667.

[jazzynico (jazzynico)]

I'm not sure it's directly related to the report, but the following console messages show when reverting a file with 3D boxes:
----
(inkscape.exe:2456): GLib-GObject-WARNING **: instance of invalid non-instantiatable type `(null)'
(inkscape.exe:2456): GLib-GObject-CRITICAL **: g_signal_handlers_disconnect_matched: assertion `G_TYPE_CHECK_INSTANCE (instance)' failed
----

[jazzynico (jazzynico)]

> when reverting a file with 3D boxes

When reverting, but also when closing the file.

[su_v (suv-lp)]

jazzynico wrote:
> When reverting, but also when closing the file.

… and also when deleting a just-created 3dbox in a new document.

> (…) on Windows XP, Inkscape trunk revision 12667.

Same warnings on OS X 10.7.5 with builds which are compiled with
- i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.9.00)

No warnings however with builds compiled with
- Apple clang version 3.1 (tags/Apple/clang-318.0.58) (based on LLVM 3.1svn),
- gcc-mp-4.6 (GCC) 4.6.3 (FSF GCC 4.6.3 compiled with MacPorts, outdated)

Warnings don't seem to depend on Glib version - they are present with these tested versions:
2.32.4, 2.34.3, 2.38.0

[jazzynico (jazzynico)]

Can also be reproduced with a box created with recent Inkscape versions. The displacement shows when the layer containing the 3D box is transformed (a translation can be created by resizing the canvas to the content).

[jazzynico (jazzynico)]

... but not only. Just tried to remove the transformation from the file created with 0.48.4, and it doesn't solve the issue.

[jazzynico (jazzynico)]

Very difficult to test. The 3D box moves all the time when editing it!

[jazzynico (jazzynico)]

Very likely related to Bug #1472892 "Objects displaced after save (3D boxes)"
<https://bugs.launchpad.net/inkscape/+bug/1472892>

[jazzynico (jazzynico)]

Attaching two new test files created with 0.91.
The only difference is that in the second one the orientation is set to landscape.
---
diff 3dbox-091.svg 3dbox-091-landscape.svg
12,14c12,14
< width="210mm"
< height="297mm"
< viewBox="0 0 744.09448819 1052.3622047"
---
> width="297mm"
> height="210mm"
> viewBox="0 0 1052.3622 744.09448"
18c18
< sodipodi:docname="3dbox-091.svg">
---
> sodipodi:docname="3dbox-091-landscape.svg">
62c62,63
< id="layer1">
---
> id="layer1"
> transform="translate(0,-308.26772)">

[jazzynico (jazzynico)]

Opening 3dbox-091 alone works as expected.
Opening 3dbox-091-landscape shows a displacement to the bottom of the document.

And now, even weirder, when opening 3dbox-091-landscape and then 3dbox-091, 3dbox-091 shows a displacement to the top of the document.

[jazzynico (jazzynico)]

Comment 2 from duplicate bug #1681593 (https://bugs.launchpad.net/inkscape/+bug/1681593/comments/2) confirms the loading order changes the 3D boxes behavior.

[Tom Delaplain (minty23185fresh)]

Additional testing (to achieve workarounds)
Inkscape version 0.92.1 r15371 (on Windows 7)
How to get the 3D boxes to snap back into position (workarounds).
1) I have not observed the snap behavior described in the Bug Description of this thread (i.e. merely selecting a box and all boxes snap back - I have not observed this to be true)
2) Grouping the boxes causes a snap back to proper positions
3) Moving the boxes to a different layer (select box then right click, Move to Layer...). Even moving them to the same layer causes snap back (Move to Layer... move from Layer 1 to Layer 1).
4) Open the file in two different instances of Inkscape. In the first instance the boxes are misplaced. In the second instance they are okay.
NOTE that none of these workarounds are permanent, they just allow one to continue working on the drawing. After save and reload the mispositioning reoccurs.

I believe the following is correct and that it is important: The boxes are NOT truly misplaced, Inkscape simply displays them in the wrong position. When the data file is opened in another application, for example Internet Explorer, the boxes are drawn in their proper positions.