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 updateIDupdateIDdraw(_: 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)
}
}
}