У меня есть пользовательский NSView с поддержкой слоев, и они переопределили метод makeBackingLayer для возврата пользовательского подкласса CALayer. Я также переопределяю wantUpdateLayer, чтобы вернуть true, тем самым полностью выбрав слойный рисунок.Поддержка NSView с поддержкой пользовательского CALayer, не вызывающего updateLayer?
override func makeBackingLayer() -> CALayer {
return Layer() // my custom class with "drawLayer:" implemented
}
override var wantsUpdateLayer:Bool{
return true
}
// never called
override func updateLayer() {
super.updateLayer()
println("updateLayer after")
self.layer?.borderWidth += 1
}
После того, как я делаю это, я считаю, что, когда я установил NSView.needsDisplay = true
он перенаправляет вызовы drawInContext пользовательского элемента слоя: метод, в отличие от updateLayer: метод. Почему это так? В моем примере я проверил, что если я удалю переопределение makeBackingLayer
, то мой updateLayer
вызывается ожидаемым образом.
Я не могу поместить на него свой палец, но другие примеры указывают на то, что когда ваш makeBackingLayer returns a custom
CALayer`, у вас действительно есть свой собственный уровень, размещенный внутри родительского слоя поддержки. (Чистая спекуляция с моей стороны)
Кроме того, существуют ли различные характеристики производительности между двумя маршрутами чертежа, учитывая, что drawIcontext CALayer: более «низкоуровневый»? См. Этот вопрос SO для получения более подробной информации по этому вопросу: Layer-backed NSView performance with rendering directly in CALayer.drawInContext:
Любое понимание будет принята с благодарностью.
У меня есть свойство точно так же, как у вас есть это выше. К сожалению, это не ответ. – Sam