When invalidating a view backed by a CATiledLayer, a previous tile remains "stuck" and isn't correctly invalidated.
This seems to happen when the view is invalidated (on the main thread), while at the same time, the tile render threads are still working on a previous version of the tile. Instead of caching the new version of the tile, the previous version is cached.
The view backed by CATiledLayer is a subview of a UIScrollView and is zoomable. The rendering of a tile can be expensive and can use the render thread for 10ms.
Example code that demonstrates this issue: https://github.com/Q42/CATiledLayerBug
tiledView.setNeedsDisplay()
See the update
function here: https://github.com/Q42/CATiledLayerBug/blob/master/TiledLayerTest/ViewController.swift#L45
This seems to be a bug in the implementation of CATiledLayer
. Since I can't fix that, does anyone know of a good workaround for this issue?
I've filed a radar for this: http://www.openradar.me/28648050
Based on some further logging I've added to the example project, I think the problem is this:
The CATiledLayer
has two render threads that draw each tile. If, during the execution of a draw(_: CGRect)
call a setNeedsDisplay
is called, the current execution of the draw
call is finished and the result is cached. The cached value is based on the previous "data source" (just the tile color in this example), rather that the updated data source.
An Apple support engineer provided me with a workaround:
updateID
field to the TiledViewdraw(_: CGRect)
call save the current updateID
updateID
draw(_: CGRect)
call, compare the saved updateID
with the current one.setNeedsDisplay
call.Extract:
override func draw(_ rect: CGRect) {
let originalID = updateID
// all actual (slow) drawing code here...
if originalID != updateID {
// dispatch a redraw request, but wait a little while first
DispatchQueue.main.asyncAfter(deadline: .now() + .milliseconds(17)) {
self.layer.setNeedsDisplayIn(rect)
}
}
}