The answer to the last post is connected to what I describe in this thread.
Actually, the issue here is related but different (the other thread addresses the question of width/height vs bounds.width/bounds.height).
Over here, I am saying that implementing originX and originY will break the bounds computation (shilo's code did not adjust the bounds). When you set origin to non-zero, then the bounds should report the shifted bounds. Let's say your origin is in the center of a 100x100 square placed at 100,100. Then, the bounds should report a rectangle (50,50,100,100) and not (100,100,100,100).
This should be fixed in SPDisplayObject.transformationMatrix, but since we do not know the actual width and height, but only the relative origin 0.0f to 1.0f, we cannot do the offsets here. You cannot query width and heigh there because they in turn query the bounds (invoking this transformationMatrix method).
Since Daniel has explained why the framework returns width/height the way it does and there is no turning back now, I have to find a workaround. I fixed the problem by storing originX and originY as absolute position values instead:
SPImage *image = [SPImage imageWithContentsOfFile:@"image.png"];
image.originX = object.width*0.5f;
image.originY = object.height*0.5f;
SPMatrix *matrix = [[SPMatrix alloc] init];
if (mScaleX != 1.0f || mScaleY != 1.0f)
[matrix scaleXBy:mScaleX yBy:mScaleY];
if (mRotationZ != 0.0f)
if (mOriginX || mOriginY)
[matrix translateXBy:-mOriginX yBy:-mOriginY];
[matrix translateXBy:mOriginX yBy:mOriginY];
[matrix translateXBy:mX-mOriginX yBy:mY-mOriginY];
return [matrix autorelease];