CANVAS size is unnessesary big for small rotation angle

[GoogleCodeExporter]

Even with preservePosition, when using a rotateAnimation with a slight
angle (+/- 5 degrees), canvas size is unnecessarily large, and spaces
images too far apart.

Any way to change this?

Eg.  100x100px image, canvas created for full rotation is 141px.

Original issue reported on code.google.com by toolman...@gmail.com on 31 May 2010 at 9:55

[GoogleCodeExporter]

Can you please provide a test page? I mean I tested new attribute and the width 
and 
height should be exactly the same as image. Check if you using newest 
version/clear 
cache/look for any mistake in code, or if you can - as mention before - send me 
a test 
case for this bug please.

Original comment by wil...@gmail.com on 1 Jun 2010 at 8:14

• Added labels: Usability

[GoogleCodeExporter]

Well i know what you mean, but unfortunatelly I guess this will not change 
because for two reasons:

1. Plugin cant tell how much you would like to rotate, so it has to take worst 
case scenario - so even if you're rotating like -+5 degree in fact I prepare 
container for 45 angle rotation - where the height and width is 
Math.sqrt(width^2 + height^2). In case its a 100x100 image its a sqrt of a 
20000 == 141. 

2. This preparation is mainly used by a mouse events. Otherwise it could lead 
to odd effects if image is rotated, but hovering on it wont do anything 
(because you're outside of a bounding box). 

However I could make this an optional argument if there would be more requests 
like that.

Original comment by wil...@gmail.com on 16 Dec 2010 at 10:46

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Quote: "1. Plugin cant tell how much you would like to rotate, so it has to 
take worst case scenario"

I have this piece of code, that's been working fine for me. (Used it in PHP a 
lot too)
Check it out:

var imgSize = new Array();
CenterX = width/2;
CenterY = height/2;
if (angle == 0 || Math.abs(angle) == 180) {
  imgSize['width'] = width;
  imgSize['height'] = height;
} else {
  if (Math.abs(angle) == 90) {
    imgSize['width'] = height;
    imgSize['height'] = width;
  } else {
    theta = (angle && angle != '') ? Math.PI/180 * angle : 0;   // Calculate Radiant from degrees
    XMin = CenterX - 0.5 * (width*Math.abs(Math.cos(theta)) + height*Math.abs(Math.sin(theta)));
    XMax = CenterX + 0.5 * (width*Math.abs(Math.cos(theta)) + height*Math.abs(Math.sin(theta)));
    YMin = CenterY - 0.5 * (width*Math.abs(Math.sin(theta)) + height*Math.abs(Math.cos(theta)));
    YMax = CenterY + 0.5 * (width*Math.abs(Math.sin(theta)) + height*Math.abs(Math.cos(theta)));
    imgSize['width'] = XMax - XMin;
    imgSize['height'] = YMax - YMin;
  }
}

Hope you'll find it useful...

Original comment by avano...@gmail.com on 17 Jan 2011 at 12:32

[GoogleCodeExporter]

Thanks Avano but you didnt get it right i guess.

Plugin cant determine how much you would like to rotate in whole time of web 
app being active. Its like guessing how much you would like animate without 
knowing anything. So I take worst case scenario that makes sure that canvas 
space is prepared for any angle that you might give. This way canvas area is 
big, but ensures a performant wise operation of NOT changing width and height 
of a canvas element on the fly [when animating].

Anyway thanks for code :)

Original comment by wil...@gmail.com on 18 Jan 2011 at 4:00

[GoogleCodeExporter]

Maybe not, but I still think I did...

I adjusted the script after posting the code above, because I'm using it for a 
kind of drawing application. (Drag/Drop, Scale and Rotate image on the fly)
I had a bounding box, to highlight the image the user is hovering over. (This 
worked great, when I used my own (crappy) code to rotate the images)
After removing my own rotation-code and (VERY easily) dropping-in jQueryRotate 
(thanks to the copying of the image's ID and Class!), this bounding box 
remained as the un-rotated image.

So I used the code above inside the _rotate:(function(){}) (That's where we 
know the angle), for both IE and Canvas, to re-size & re-position the 
_temp.style and the _canvas/_container to match. (the IE _container already is 
the correct size)

Don't know about the animations though...
I have no need for that (yet ;D)

I attached the file for all to see. (I'm just a novice, so bear with me)
Seems to work for FireFox, Opera 9 and IE8 (others too, but those use CSS 
rotation)

Original comment by avano...@gmail.com on 18 Jan 2011 at 5:32

Attachments:

• jQueryRotate1.7edit.js

[GoogleCodeExporter]

Oh now i get you, but its a specific use case that is not valid for most of the 
users :) I could put that as an optional parameter but not sure will it instead 
of adding feature will just bloat a code that is already not too small (want to 
have it smaller :/)

Original comment by wil...@gmail.com on 19 Jan 2011 at 7:47

[GoogleCodeExporter]

You're right.
If I wouldn't show any borders, I wouldn't even know the size is different.
It's pretty useless in most cases.
I suggest if anyone would want the canvas re-sized, they get the code from here.

However, would this solve the original problem (reported by Toolman)?

Original comment by avano...@gmail.com on 20 Jan 2011 at 11:48

[GoogleCodeExporter]

I think a main problem was before I introduced a way of having a image on 
position:absolute. Before it just extends a size around image that even small 
rotation makes space around image quite big. Now you dont see that problem 
anymore, but of course problem still kinda apply for mouse events. But again - 
recalculating that for every animation frame would be quite bad in permormance 
way so I guess I will not introduce this change into main trunk.

Original comment by wil...@gmail.com on 20 Jan 2011 at 2:13

[GoogleCodeExporter]

I think a main problem was before I introduced a way of having a image on 
position:absolute. Before it just extends a size around image that even small 
rotation makes space around image quite big. Now you dont see that problem 
anymore, but of course problem still kinda apply for mouse events. But again - 
recalculating that for every animation frame would be quite bad in permormance 
way so I guess I will not introduce this change into main trunk.

Original comment by wil...@gmail.com on 20 Jan 2011 at 2:13

[GoogleCodeExporter]

Agreed.
Running about 40 lines of (extra) code on each angle change, would probably 
slow things down quite a bit.

Original comment by avano...@gmail.com on 20 Jan 2011 at 2:27

[GoogleCodeExporter]

Original comment by wil...@gmail.com on 25 Jan 2011 at 11:37

• Added labels: Type-Enhancement, Priority-Low
• Removed labels: Type-Defect, Priority-Medium

[GoogleCodeExporter]

Original comment by wil...@gmail.com on 25 Jan 2011 at 11:38

• Changed title: CANVAS size is unnessesary big for small rotation angle

[GoogleCodeExporter]

As explained above - this would introduce quite bad performance change. Anyway 
upcoming version of jQueryRotate that will rotate any elements instead of 
images should solve this problem.

Original comment by wil...@gmail.com on 28 Mar 2011 at 7:06

• Changed state: WontFix