Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: e2ffafdf3851abda0161f4adc5cfdc60fd826a28
      
https://github.com/WebKit/WebKit/commit/e2ffafdf3851abda0161f4adc5cfdc60fd826a28
  Author: Simon Fraser <[email protected]>
  Date:   2023-03-25 (Sat, 25 Mar 2023)

  Changed paths:
    M Source/WebKit/Shared/RemoteLayerTree/RemoteLayerBackingStore.mm
    M Source/WebKit/Shared/RemoteLayerTree/RemoteLayerBackingStoreCollection.mm

  Log Message:
  -----------
  [UI-side compositing] Unpainted regions (missing tiles) when scrolling with 
the keyboard
https://bugs.webkit.org/show_bug.cgi?id=254466
rdar://107163092

Reviewed by Tim Horton.

When scrolling around a long page with Home/End keys, it's common for page 
tiles to be unparented
and reparented, exercising the logic in RemoteLayerBackingStoreCollection which 
maintains the
m_unparentedBackingStore set.

If a layer which does not need display (i.e. is "clean" and has not been made 
volatile) is
reparented, we'd fail to fetch a new ImageBufferBackendHandle from the GPU 
Process, but set the
`BackingStoreChanged` dirty bit, so the UI process would try to set layer 
contents but to nil.

Fix by adding layers which are pulled out of `m_unparentedBackingStore` to the
`m_backingStoresNeedingDisplay` set, which results in them participating in
`RemoteRenderingBackend::prepareBuffersForDisplay()` which will ensure we get a 
new backend handle
from the GPU process.

This is hard to test, but I added an assertion in 
RemoteLayerBackingStore::encode() that we're
encoding a non-null handle which would have caught this.

* Source/WebKit/Shared/RemoteLayerTree/RemoteLayerBackingStore.mm:
(WebKit::hasValue):
(WebKit::RemoteLayerBackingStore::encode const):
* Source/WebKit/Shared/RemoteLayerTree/RemoteLayerBackingStoreCollection.mm:
(WebKit::RemoteLayerBackingStoreCollection::backingStoreWillBeDisplayed):

Canonical link: https://commits.webkit.org/262120@main


_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes

Reply via email to