To comment on the following update, log in, then open the issue:
http://www.openoffice.org/issues/show_bug.cgi?id=93663
User aw changed the following:
What |Old value |New value
================================================================================
Status|NEW |STARTED
--------------------------------------------------------------------------------
------- Additional comments from [EMAIL PROTECTED] Wed Sep 17 09:52:13 +0000
2008 -------
AW: This is definitely from aw033. In the integrated version, for 3D there is
some kind of mixed stuff. The graphics are done using primitives completely, but
the HitTest and other stuff at the model is still done using the old 3D
geometry. I already started removing the old geometry (what means: all it's
usages) before aw033 integration and i am adding those changes now.
AW: Works well for all 3Dgraphics in the Apps, but leads to changed
visualisations in Chart2. Reason is the mechanisms in 3D. There are principally
2 mechanisms in 3D working in the background:
(1) The ViewTranaformation is always calculated so that all conent of a Scene is
projected into the 2D geometry of the scene (SnapRect).
(2) When model changes occurr at something that geometrically changes the
scene's 3D content, it is necessary to adapt the 2D geometry of the scene to
reflect the change in an intuitive way to the user.
One example for (2): Two extruded ellipses in a scene, one is moved while scene
is entered and that one selected. The ellipse is moved outside the current 2D
bounds of the scene. Without (2), the canged content would be rendered in the
current 2D bounds ofthe scene, making the objects getting smaller and somewhat
'snap' back to prior positions. (2) is also neded for objcet insertion, removal,
line width and other 3D geometry changes and so on.
Problem with (2) is that the old version is hard coded into the model, e.g.
changing the line width of a 3D object which is member of a 2D scene will do
mechanism (2) using it's various update mechanisms. This is often not wanted
when using the API or e.g. at load time (the SnapRect needs to be set again at
end of scene loading). Since the old stuff does not use model-view-controller
seperation, there is no way to decise at model level if the change results in a
unser interaction where (2) would be needed or someting else where (2) should be
avoided.
To go in the right direction, i completely removed (2) from the model's updating
mechanisms and created a helper (E3DModifySceneSnapRectUpdater) for (2). It gets
a SdrObject and - if all circumstancs are fulfilled - saves the SdrScene and
it's current 3D transformation stack (ViewInformation3D). In the destructor, it
uses the old view transformation and the changed 3D geometry to calculate a new
projection BoundRect which is the new SnapRect for te scene and sets it. I
changed all interactive parts to use this encapsulation when modifying 3D
objects (also Undo/Redo) to get some closer to MVC-separation (though i had to
make some compromises...). Ths works well, ahd (2) is no more used in reload and
chart construction.
Chart still looks differet than before, need to get IHA and discuss with her...
---------------------------------------------------------------------
Please do not reply to this automatically generated notification from
Issue Tracker. Please log onto the website and enter your comments.
http://qa.openoffice.org/issue_handling/project_issues.html#notification
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
