RESOLVED INVALID89204
[chromium] Normalize scale-related names
https://bugs.webkit.org/show_bug.cgi?id=89204
Summary [chromium] Normalize scale-related names
vollick
Reported 2012-06-15 06:44:25 PDT
We have members that exist in many different spaces, and their names are often confusing. Things will become even more confusing as the device scale factor is applied. We need to agree on names for these spaces, identify which member is in which space, and rename the members so it is clear at a glance which space they belong to. Where possible, conforming to this document would be a good idea http://trac.webkit.org/wiki/ScalesAndZooms. Please comment if you have suggestions for names, or names that definitely need changing.
Attachments
Dana Jansens
Comment 1 2012-06-15 07:26:56 PDT
This largely depends on what device scale approach we use. Assuming we scale in LRC and keep the rest in CSS pixels.. - Surface "contentRect" is actually "surfaceRect" (analogous to layer-space) - Framebuffer space was introduced to say physical pixels before viewport/window transforms, but is no longer physical pixels after the change, and just becomes screenSpace again. - We could rename layer/surface space to layout space possibly.
James Robinson
Comment 2 2012-06-15 14:23:10 PDT
(In reply to comment #1) > This largely depends on what device scale approach we use. Assuming we scale in LRC and keep the rest in CSS pixels.. nit: I think we want to keep the rest in logical pixels (not CSS pixels) - i.e. page zoom is already baked in to the values we get on GraphicsLayers, etc. > - Surface "contentRect" is actually "surfaceRect" (analogous to layer-space) > - Framebuffer space was introduced to say physical pixels before viewport/window transforms, but is no longer physical pixels after the change, and just becomes screenSpace again. > - We could rename layer/surface space to layout space possibly.
vollick
Comment 3 2012-06-20 11:14:57 PDT
It seems that there is no longer as urgent a need for renaming given 86882. contentBounds, means the bounds of the texture the layer (or render surface) manages. For example, for an image, it's the dimensions of the image, and for a render surface, it's the dimensions of the texture backing the surface. I am going to close this for now.
Note You need to log in before you can comment on or make changes to this bug.