New:
APZC needs to base displayport calculation on visible rect of composition bounds by tnikkel@gmail.com
Let H be the height of the scroll port of a scrollable element. Let V be the
visible height. APZC will calculate a displayport that is basically some
multiple, say k, of H tall. Making it k*H tall.
If we then translate that display port rect into layer margins (like
bug
957668) and apply those margins to the visible rect we will get a resulting
display port that is (k-1)*H + V. In other words we only subtract the
non-visible height, all of the extra multiples of H remain.
So just using layer margins like
bug 957668 won't be enough to solve our memory
woes. We'll need APZC to consider the visible rect when calculating the
display port.
Referenced Bugs:
https://bugzilla.mozilla.org/show_bug.cgi?id=957668
[
Bug 957668] Change the displayport representation in layout to be
layerpixel margins rather than csspixel offset/size
CC: → mstange@themasta.com
Markus Stange [:mstange]
said:
(In reply to Timothy Nikkel (:tn) from comment #0)
> Let H be the height of the scroll port of a scrollable element. Let V be the
> visible height. APZC will calculate a displayport that is basically some
> multiple, say k, of H tall. Making it k*H tall.
>
> If we then translate that display port rect into layer margins
I don't understand this part. Isn't the point of the translation to margins to
stop using a multiple of the scrollport height as the start of the calculation?
I thought in the world with displayport margins there would no longer be a k,
only a margin in screen pixels that's based on the current scroll velocity.
Timothy Nikkel (:tn)
said:
The patches in
bug 957668 very shallowly convert the display port to layer
margins. In fact APZC isn't changed at all by those patches. Instead when
content gets a new display port from APZC it then translates it into layer
margins. Does that make it clearer?
Basically APZC needs to modify it's display port calculation and I don't think
there is any way it can intelligently do so without knowing the visible rect.
Whether we convert to layer margins there or not doesn't matter, the math will
work out the same.
The reason that layer margins are important is the following case: we zoom
(increase the resolution) of a document, APZC will send this zoom change for
layout to update to before APZC changes any displayports on non-root scrollable
frames. So until APZC sends us new display ports for the child scrollables that
takes into account the new zoom layout needs to do something to keep those
displayports reasonable. This is when we convert the existing display port to
the _old_ layer pixels (before zoom), convert that to layer margins, apply
those layer margins to the new visible rect (this time we are in the new layer
pixels). This way we expand the display port from the visible rect by roughly
the same number of layer pixels.
Timothy Nikkel (:tn)
said:
(In reply to Markus Stange [:mstange] from comment #4)
> calculation? I thought in the world with displayport margins there would no
> longer be a k, only a margin in screen pixels that's based on the current
> scroll velocity.
So we could calculate the exact same rect, then convert it into margins
expressed in screen pixels. But these will end up being too big in some cases
(imagine a 100000px tall iframe). I'm saying we need to change the way APZC
calculates the rect in the first place. And I'm further saying that it needs
the visible rect in order to calculate it in a reasonable way. How else could
APZC calculate a displayport for a 10000px tall iframe unless it knows what
part of the iframe is visible? Currently it says the entire iframe is visible.
