[webkit-dev] Can someone explain tx/ty?

[Maciej Stachowiak]

On Aug 23, 2010, at 10:20 AM, David Hyatt wrote:

> 
> On Aug 23, 2010, at 12:11 PM, David Hyatt wrote:
> 
>> 
>>> (hopefully less verbose, but you get the idea). tx, ty could be named parentOffsetFromLayerCoordinates or something. This seems to be the intent of the names - that x,y is a point and tx, ty is a translation. But this doesn't work in point/size logic. You repeatedly add x(), y() to tx, ty to get a new tx, ty. But that means you're adding a point to a size and expecting to get a new size - but that's not how it works.
>>> 
>> 
>> I think a helper method that does the right thing solves this problem (rather than having to flip what x/y and tx/ty mean just to do some math operation).
>> 
>> dave
> 
> Just to clarify, if tx/ty turned into an IntSize offset, I think you could just add a helper method like .asOffset() to IntPoint to solve this particular problem.
> 
> Instead of 
> 
> tx += x();
> ty += y();
> 
> You could write:
> 
> offset += location().asOffset();
> 
> I'd also have no objection to just building that right into RenderBox...
> 
> offset += locationOffset();

I think the current code is wrong in thinking of tx/ty as an offset instead of a point. Once the local offset is added, they are passed directly to painting methods. The first place I looked at, RenderBoxModelObject::paintBoxShadow, starts with:

 IntRect rect(tx, ty, w, h);

Then it does some rect math before passing a rect based on this to the GraphicsContext. 

I couldn't find any place where tx, ty are actually used in an obviously offset-like way. As another data point, several places make an IntPoint from tx, ty, none make an IntSize.

You usually list the location first, not the offset, when adding coordinates. 

They get treated as a point pretty much all over the place. If we converted all that code to using IntPoint/IntSize, and tx/ty got replaced with an IntSize, we'd constantly have to convert it to an IntPoint to actually do any painting. If you constantly have to convert it to a point, it should just be a point. By contrast, x()/y() are fairly often used as an IntSize (sometimes they are even passed to the IntSize constructor), though they also get used in a point-like way in other code.

To some extent it's arbitrary what you consider a point and what you consider an offset. A point is just an offset from the origin, for some defined origin. In painting code, it's convenient for the points to be in the CTM space, since that is what you need whenever you get down to a GraphicsContext call.

Regards,
Maciej