Wow...well when trying to alter the dynamic registration class to use a matrix method I came across an anoying bug in flash. Once you apply certain transformations using a transform matrix some of the normal properties of a display object, in my particular case scaleY, returned 0 or a wrong value. Hmm....I’m not sure if this bug will reappear when the rotate scale class is modified. It sure is a pain!

weyforth - 17 June 2008 06:43 PM

Once you apply certain transformations using a transform matrix some of the normal properties of a display object, in my particular case scaleY, returned 0 or a wrong value.

I’m developing on flex and the scaleX and scaleY maintain the asigned value regardless the transformation aplied with the transform matrix. Instead, rotation change with the transformation.

Hey I implemented the matrix methods into the dynamic registration class so I could do some accurate testing. I spend all day yesterday and half of today trying my best to get the best performance out of each method, and the results can be seen below. It turns out the matrix methods are slightly slower than the methods used in the original dynamic registration class, which I wasn’t really expecting, but the difference is very slight as I had to increase the number of tests to identify it. So if you are only performing a few operations the difference should be negligible. Anyway I hope these test results are of some use. If anyone wants the modified dynamic registration class or the test fla just say

DYNAMIC REGISTRATION METHOD TEST
------------------------------------------------------------------
10 identical transformations, scaling rotating and moving, performed on two sprites using different dynamic registration classes. Set of transformations repeated 10000 times on each sprite

TEST #1
original class:  625 ms
matrix class:  670 ms

TEST #2
original class:  624 ms
matrix class:  672 ms

TEST #3
original class:  624 ms
matrix class:  678 ms

TEST #4
original class:  618 ms
matrix class:  672 ms

TEST #5
original class:  658 ms
matrix class:  677 ms

TEST #6
original class:  621 ms
matrix class:  680 ms

TEST #7
original class:  600 ms
matrix class:  689 ms

TEST #8
original class:  598 ms
matrix class:  694 ms

TEST #9
original class:  612 ms
matrix class:  698 ms

TEST #10
original class:  594 ms
matrix class:  699 ms

RESULTS (AVERAGE OVER 10 TESTS)
------------------------------------------------------------------
original class:  617.4 ms
matrix class:  682.9 ms

Of course we would like the class/fla. I haven’t had time to test this yet, but by the end of next week I hope to have a version commited to the svn. So if one of you already have a whole class that just needs to be tested/committed without changes, please post it so I can test and commit ASAP.

Attached are the two classes, old and new, along with the fla I used to test them. I also included the Consts class as I think I put it in a different location to the original in the SVN. Sorry about the state of the modified class, I optimized it so that it runs as quick s possible, so If you need any help understanding or commenting it just say. There are alos a few extra features in the classes that aren’t in the original dynamic registration class, such as the centreRegistration function. enjoy

There is a problem with the matrix transform method. When used, the scaleX, scaleY, width and height remain unchanged and in certain cases we need to know the changed width and height. This is due to the design of DisplayObject and UIComponent (I’m working in flex, so Multitouchable extends UIComponent and UIComponent extend DisplayObject). DisplayObject have the properties transform, scaleX, scaleY, width, height and rotation and UIComponent have the same properties but transform and rotation. When we change the transform property, this change the DisplayObjetc.scaleX, DisplayObject.scaleY, DisplayObjetc.width, DisplayObjetc.height and DisplayObjetc.rotation. UIComponent only extend rotation and the other properties are reimplemented in UIComponent, so any change to DisplayObject.scaleX doen’t reflect on UIComponent.scaleX.

This is my changed code. You can add this function to the dynamic registration class:

The finishDoTransform is only needed in flex if extend UIComponent.

*bookmark*

looks very interesting

Indeed! I agree with the Falcon.

Just a quick note about the two different methods, I’m kinda leaning more towards the matrix method. I don’t really like the way the original method works, as it is tranforming the object and then afterwards translating it to the position it SHOULD be in. The matrix method makes all these adjustments using a matrix before it uses it to transform the object itself. Much cleaner and less clumsey in my opinion. What about everyone else?

Really funny is that MS’s Surface has the same problem with rotation and zooming out ) , you can see it in the Live Labs demo video (the Seadragon one with Shadowbox at the end)
When the guy uses the picture app rotating and zooming out , he has the same bug ) , really funny.

Related Blog Post: http://gasi.ch/blog/zooming-in-flash-flex/

Nice find nuiman

Taha

I can’t seem it get this to work. weyforth can u help or anyone?

we took a similar approach to fix the rotate bug using matrix transformations, but are using the TouchLibrary from Mark as a base.
rotating looks way better now *smile*

btw: it’s quite exhausting to read the svn code of touchlib with all these cc-fixes, dead code blocks and no doc.
any chance of getting someone to clean up a little?

Do you have a class for marks libary?