Spanspek

In my last entry, I demonstrated that when a Raphael SVG object is rotated, its coordinate system is also rotated. In fact, when the object is returned to a rotational angle of 0 degrees, it jumps to the location it would have moved to had it not been rotated. So the issue is, how can one move an object which has been rotated away from its original angle (whatever shape and orientation it had when it was created). I previously considered using trigonometric calculations to adjust both x and y coordinates to make the object move to where it would be if its angle of rotation had been 0 degrees. But I now realise that this would not have worked properly as the distance the object moves when it is rotated away from 0 degrees is the same as it would have moved when it was at 0 degrees' rotation. If my memory of trigonometry serves me correctly, that would require tan, not sin or cos. I'm sure that, with a little revision, I could work it out. But I suspect that some of those mathematical functions result in a performance hit, especially as they'd have to be performed with every mousemove event. I've no doubt that SVG or VML functions already employ such calculations, even though they're done by the Javascript engine which is most likely written in C or C++ and therefore performs at least an order of magnitude faster than the interpreted Javascript which invokes them. Or maybe such calculations only happen once, when the object is rotated and then a completely different coordinate system is maintained in memory. Since I understand nothing about Javascript engines, I could be talking completely through my hat. So I decided to try a simpler approach that I alluded to before: rotate the object back to 0 degrees before moving it and then re-rotate it to whatever angle it was before the move. I could "undo" the rotation on the mousedown and "redo" the rotation on the mouseup, but the user would see the object in an unrotated state during the mousemove. I decided to so these operations for every mousemove event. Here's the demo. It has the same "Rotate"/"Unrotate" button under the canvas (scroll down a bit if you can't see it) as before. If you examine the Javascript, you'll notice there are only a few lines added. I don't notice any performance difference between the previous one and this, even though the Javascript engine is probably working a bit harder. WRONG! There is a noticeable performance hit. At first, I thought there wasn't because I forgot how smooth movement is without the modifications to the previous script. And to the user, it looks as if the object is moving smoothly fairly smoothly, with no blurring due to redraws even though, one assumes, redraws are occurring. I'm not using a superfast machine either: it's an old IBM R30 running Opensuse 11.0 (Linux) with KDE4 and Firefox 3 (FF3 is required for scalable vector graphics). So, with this key functionality in place, I can continue developing the "stageplan" application.