I think this is because our sample state get confused. I'll try to explain by example. Out sample state always has two entries. Here is how a sequence of compositor transactions goes in the middle of doing the keyboard scrolling via pure relative smooth scroll updates sent to apz. transaction 1 sampled state: 814, 814. metrics: 837. sampled states have scroll offset 814 and 814 (we'll see why the sampled states have equal scroll offset later) we pop one we push a new state with scroll offset 837 that comes from our metrics, it was updated from 814 to 837 by the active scroll animation on a previous transaction. we advance our scroll animation and update our metrics to 862. we get a notify layers updated call, it has a scrollOffsetUpdate (the purerelative smooth scroll request) so we update both sampled states to our metrics value (862) transaction 2 sampled state: 862, 862. metrics: 862. sampled states have scroll offset 862 and 862 we pop one 862 we push a new state with scroll offset 862 that comes from our metrics, it was updated from 837 to 862 by the active scroll animation on a previous transaction. we advance our scroll animation and update our metrics to 885. transaction 3. sampled state: 862, 862. metrics: 885. sampled states have scroll offset 862 and 862 we pop one 862 we push a new state with scroll offset 885 that comes from our metrics, it was updated from 862 to 885 by the active scroll animation on a previous transaction. we advance our scroll animation and update our metrics to 909. We use the same scroll offset in transaction 3 as in transaction 2 (862) so the transaction is empty and we don't paint anything. I _think_ the problem here is that we treat a smooth scroll request as a scrollOffsetUpdate, but it doesn't update the scroll offset, it leaves it alone, it just starts a smooth scroll animation which will update the scroll offset in the future.
Bug 1684520 Comment 26 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
I think this is because our sample state get confused. I'll try to explain by example. Our sample state always has two entries. Here is how a sequence of compositor transactions goes in the middle of doing the keyboard scrolling via pure relative smooth scroll updates sent to apz. transaction 1 sampled state: 814, 814. metrics: 837. sampled states have scroll offset 814 and 814 (we'll see why the sampled states have equal scroll offset later) we pop one we push a new state with scroll offset 837 that comes from our metrics, it was updated from 814 to 837 by the active scroll animation on a previous transaction. we advance our scroll animation and update our metrics to 862. we get a notify layers updated call, it has a scrollOffsetUpdate (the purerelative smooth scroll request) so we update both sampled states to our metrics value (862) transaction 2 sampled state: 862, 862. metrics: 862. sampled states have scroll offset 862 and 862 we pop one 862 we push a new state with scroll offset 862 that comes from our metrics, it was updated from 837 to 862 by the active scroll animation on a previous transaction. we advance our scroll animation and update our metrics to 885. transaction 3. sampled state: 862, 862. metrics: 885. sampled states have scroll offset 862 and 862 we pop one 862 we push a new state with scroll offset 885 that comes from our metrics, it was updated from 862 to 885 by the active scroll animation on a previous transaction. we advance our scroll animation and update our metrics to 909. We use the same scroll offset in transaction 3 as in transaction 2 (862) so the transaction is empty and we don't paint anything. I _think_ the problem here is that we treat a smooth scroll request as a scrollOffsetUpdate, but it doesn't update the scroll offset, it leaves it alone, it just starts a smooth scroll animation which will update the scroll offset in the future.
I think this is because our sample state get confused. I'll try to explain by example. Our sample state always has two entries. Here is how a sequence of compositor transactions goes in the middle of doing the keyboard scrolling via pure relative smooth scroll updates sent to apz. The numbers given are the vertical scroll offset. transaction 1 sampled state: 814, 814. metrics: 837. sampled states have scroll offset 814 and 814 (we'll see why the sampled states have equal scroll offset later) we pop one we push a new state with scroll offset 837 that comes from our metrics, it was updated from 814 to 837 by the active scroll animation on a previous transaction. we advance our scroll animation and update our metrics to 862. we get a notify layers updated call, it has a scrollOffsetUpdate (the purerelative smooth scroll request) so we update both sampled states to our metrics value (862) transaction 2 sampled state: 862, 862. metrics: 862. sampled states have scroll offset 862 and 862 we pop one 862 we push a new state with scroll offset 862 that comes from our metrics, it was updated from 837 to 862 by the active scroll animation on a previous transaction. we advance our scroll animation and update our metrics to 885. transaction 3. sampled state: 862, 862. metrics: 885. sampled states have scroll offset 862 and 862 we pop one 862 we push a new state with scroll offset 885 that comes from our metrics, it was updated from 862 to 885 by the active scroll animation on a previous transaction. we advance our scroll animation and update our metrics to 909. We use the same scroll offset in transaction 3 as in transaction 2 (862) so the transaction is empty and we don't paint anything. I _think_ the problem here is that we treat a smooth scroll request as a scrollOffsetUpdate, but it doesn't update the scroll offset, it leaves it alone, it just starts a smooth scroll animation which will update the scroll offset in the future.
I think this is because our sample state get confused. I'll try to explain by example. Our sample state always has two entries. Here is how a sequence of compositor transactions goes in the middle of doing the keyboard scrolling via pure relative smooth scroll updates sent to apz. The numbers given are the vertical scroll offset. transaction 1 sampled state: 814, 814. metrics: 837. sampled states have scroll offset 814 and 814 (we'll see why the sampled states have equal scroll offset later) we pop one we push a new state with scroll offset 837 that comes from our metrics, it was updated from 814 to 837 by the active scroll animation on a previous transaction. we advance our scroll animation and update our metrics to 862. sampled state: 814, 837. metrics: 862. we get a notify layers updated call, it has a scrollOffsetUpdate (the purerelative smooth scroll request) so we update both sampled states to our metrics value (862) transaction 2 sampled state: 862, 862. metrics: 862. sampled states have scroll offset 862 and 862 we pop one 862 we push a new state with scroll offset 862 that comes from our metrics, it was updated from 837 to 862 by the active scroll animation on a previous transaction. we advance our scroll animation and update our metrics to 885. transaction 3. sampled state: 862, 862. metrics: 885. sampled states have scroll offset 862 and 862 we pop one 862 we push a new state with scroll offset 885 that comes from our metrics, it was updated from 862 to 885 by the active scroll animation on a previous transaction. we advance our scroll animation and update our metrics to 909. We use the same scroll offset in transaction 3 as in transaction 2 (862) so the transaction is empty and we don't paint anything. I _think_ the problem here is that we treat a smooth scroll request as a scrollOffsetUpdate, but it doesn't update the scroll offset, it leaves it alone, it just starts a smooth scroll animation which will update the scroll offset in the future.
I think this is because our sample state get confused. I'll try to explain by example. Our sample state always has two entries. Here is how a sequence of compositor transactions goes in the middle of doing the keyboard scrolling via pure relative smooth scroll updates sent to apz. The numbers given are the vertical scroll offset. transaction 1 sampled state: 814, 814. metrics: 837. sampled states have scroll offset 814 and 814 (we'll see why the sampled states have equal scroll offset later) we pop one we push a new state with scroll offset 837 that comes from our metrics, it was updated from 814 to 837 by the active scroll animation on a previous transaction. we advance our scroll animation and update our metrics to 862. sampled state: 814, 837. metrics: 862. we get a notify layers updated call, it has a scrollOffsetUpdate (the purerelative smooth scroll request) so we update both sampled states to our metrics value (862) transaction 2 sampled state: 862, 862. metrics: 862. sampled states have scroll offset 862 and 862 we pop one 862 we push a new state with scroll offset 862 that comes from our metrics, it was updated from 837 to 862 by the active scroll animation on a previous transaction. we advance our scroll animation and update our metrics to 885. sampled state: 862, 862. metrics: 885. transaction 3. sampled state: 862, 862. metrics: 885. sampled states have scroll offset 862 and 862 we pop one 862 we push a new state with scroll offset 885 that comes from our metrics, it was updated from 862 to 885 by the active scroll animation on a previous transaction. we advance our scroll animation and update our metrics to 909. We use the same scroll offset in transaction 3 as in transaction 2 (862) so the transaction is empty and we don't paint anything. I _think_ the problem here is that we treat a smooth scroll request as a scrollOffsetUpdate, but it doesn't update the scroll offset, it leaves it alone, it just starts a smooth scroll animation which will update the scroll offset in the future.
I think this is because our sample state get confused. I'll try to explain by example. Our sample state always has two entries. Here is how a sequence of compositor transactions goes in the middle of doing the keyboard scrolling via pure relative smooth scroll updates sent to apz. The numbers given are the vertical scroll offset. transaction 1 sampled state: 814, 814. metrics: 837. sampled states have scroll offset 814 and 814 (we'll see why the sampled states have equal scroll offset later) we pop one 814 we push a new state with scroll offset 837 that comes from our metrics, it was updated from 814 to 837 by the active scroll animation on a previous transaction. we advance our scroll animation and update our metrics to 862. sampled state: 814, 837. metrics: 862. we get a notify layers updated call, it has a scrollOffsetUpdate (the purerelative smooth scroll request) so we update both sampled states to our metrics value (862) transaction 2 sampled state: 862, 862. metrics: 862. sampled states have scroll offset 862 and 862 we pop one 862 we push a new state with scroll offset 862 that comes from our metrics, it was updated from 837 to 862 by the active scroll animation on a previous transaction. we advance our scroll animation and update our metrics to 885. sampled state: 862, 862. metrics: 885. transaction 3. sampled state: 862, 862. metrics: 885. sampled states have scroll offset 862 and 862 we pop one 862 we push a new state with scroll offset 885 that comes from our metrics, it was updated from 862 to 885 by the active scroll animation on a previous transaction. we advance our scroll animation and update our metrics to 909. We use the same scroll offset in transaction 3 as in transaction 2 (862) so the transaction is empty and we don't paint anything. I _think_ the problem here is that we treat a smooth scroll request as a scrollOffsetUpdate, but it doesn't update the scroll offset, it leaves it alone, it just starts a smooth scroll animation which will update the scroll offset in the future.