Bugzilla

Had a discussion with Jnicol and jrmuizel:

## The visible rect and building rects

- Same representation and coordinate space as the display items:
  - they are in local layout space (relative to the closest transform),
  - stored as nsRects which implies very few bits for the fractional parts.

The building rect is not a property of the display item, it is rather "the state of the visible rect during the gecko displaylist building traversal traversal, when we saw that particular item, that we use in the WR displaylist building traversal (aka painting)" in other words it is conceptually more like cached information about a state at particular points of the first traversal of the display list we reuse for convenience in the next traversal, than a property of the display items themselves.

Ideally we'd prefer for the building rect to not exist. We don't actually use it for many things but it occupies 4 x 32bits per display items. Instead it would be better if we either:
 - build it during the WR DL building traversal, similar to how we build the visible rect during gecko DL building.
 - somehow lazily reconstruct at points of the traversal where we need it.

## The root of the problem

The problem boils down to the fact that we compute the visible rect in local space AND store it in nscoord which cannot represent anything smaller than 1/60.

As a result is is very imprecise (conservatively bigger than it needs to be) when large scales area applied since we have to apply the inverse of the transform to put the parent visible rect in the local space of the transformed child items. This means that we have to either:
 - represent it with floating point numbers
 - not use it for things that can't afford to be orders of magnitude wrong (such as deciding allocation sizes).

## What can we do

In practice we can't represent the visible rect with floats, because it interacts with a lot of things that are in nscoords and for most of these things it's OK for the visible rect to be very conservatively big. More generally we don't want to change the visible rect because of how much code interacts with it.

We want to change either the building rect or the code that uses it in the webrender fallback path. Right now the building rect is born out of the Gecko DL building's visible rect which is too imprecise (and can't be easily fixed), so we want to generate this information differently: probably as state of the WR DL building descent using floating point numbers (and possibly more lazily if that's not too hard to do).

Had a discussion with Jnicol and jrmuizel:

## The visible rect and building rects

- Same representation and coordinate space as the display items:
  - they are in local layout space (relative to the closest transform),
  - stored as nsRects which implies very few bits for the fractional parts.

The building rect is not a property of the display item, it is rather "the state of the visible rect during the gecko displaylist building traversal traversal, when we saw that particular item, that we use in the WR displaylist building traversal (aka painting)" in other words it is conceptually more like cached information about a state at particular points of the first traversal of the display list we reuse for convenience in the next traversal, than a property of the display items themselves.

Ideally we'd prefer for the building rect to not exist. We don't actually use it for many things but it occupies 4 x 32bits per display items. Instead it would be better if we either:
 - build it during the WR DL building traversal, similar to how we build the visible rect during gecko DL building.
 - somehow lazily reconstruct at points of the traversal where we need it.

## The root of the problem

The problem boils down to the fact that we compute the visible rect in local space AND store it in nscoord which cannot represent anything smaller than 1/60.

As a result is is very imprecise (conservatively bigger than it needs to be) when large scales area applied since we have to apply the inverse of the transform to put the parent visible rect in the local space of the transformed child items. This means that we have to either:
 - represent it with floating point numbers
 - not use it for things that can't afford to be orders of magnitude wrong (such as deciding allocation sizes).

later that same imprecise rect is scaled back up, which is where things blow up but really the information loss when scaling down is the source of trouble.

## What can we do

In practice we can't represent the visible rect with floats, because it interacts with a lot of things that are in nscoords and for most of these things it's OK for the visible rect to be very conservatively big. More generally we don't want to change the visible rect because of how much code interacts with it.

We want to change either the building rect or the code that uses it in the webrender fallback path. Right now the building rect is born out of the Gecko DL building's visible rect which is too imprecise (and can't be easily fixed), so we want to generate this information differently: probably as state of the WR DL building descent using floating point numbers (and possibly more lazily if that's not too hard to do).