Rotate and zoom should be simultaneous

Bug #677273 reported by Alfrenovsky on 2010-11-19
This bug affects 1 person
Affects Status Importance Assigned to Milestone

Bug Description

When using the zoom feature the presentation first rotates very fast and then uses the given time to zoom in.

I think both rotation and zooming should be done simultaneously like prezi does.

description: updated

At the moment, the transition from one view to another is just a linear interpolation between the two transformation matrices describing the views. It might appear differently, but the rotation, zoom and translation happen simultaneously. As soon as I find some time for it, I'll look into more sophisticated algorithms for the transitions between views.


Changed in jessyink:
importance: Undecided → Wishlist
status: New → Triaged
Alfrenovsky (alfredo-fing) wrote :

Now I tested it with low zooms and it works fine.
With high zooms doesn't

Lets say I have a 1024x768 slide.with 24pt text. if I zoom and rotate 45 degrees to see only one of the 24pt fonts in full screen I notice a full rotate after start zooming.

Tested in firefox and chrome.

Alfrenovsky (alfredo-fing) wrote :

forgot to say. Tested in firefox and chrome under Linux.

Alfrenovsky (alfredo-fing) wrote :

I think the problem is the "/det" division.

With high zooms, the divisions should be done at the end to avoid rounding problems.

I agree that the calculation of the determinant of a matrix is often not very stable in numerical terms. However, I don't think that this is the problem in this case. The division by the determinant is only involved in the calculation of the inverse of the matrix, which in term is only used for calculating the new view. So far, I have not seen any problems with the areas the views display, which is where problems with the determinant should show up. The transition itself is only a a linear combination of two matrices (i.e. Matrix1 * a + Matrix2 * (1 - a) for a = 0..1).

Should I have mistaken your point, please let me know. Also, if you have example files that show how a different calculation method improves the transition, please attach them to the bug.

I think you can find this problem solved here

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers