Changing a CALayer in a menu callback doesn't trigger re-draw

[zittix]

If in a menu action we change some properties of a CALayer such as:

var af = CGAffineTransformMakeScale(scale/100.0,scale/100.0);
[myLayer setAffineTransform:af];

The update is not applied to the layer until the mouse is moved (tested on Safari 7.0 and Chrome 31.0).

The provided fix force the update of the CALayer tree at the end of the menu callback.

[cappbot]

Milestone: Someday. Label: #new. What's next? A reviewer should examine this issue.

[aljungberg]

Doesn't CALayer do a perform on runloop for that [CALayer runLoopUpdateLayers], and that's why the update does happen once the mouse moves?

So it seems the real problem is that the run loop doesn't enter a second iteration here. Probably we got to this point via a non-run-loop path and the comment nearby seems to describe a similar problem.

So, maybe what we should actually be doing instead of adding more layers of custom calls is to just pump the run loop or schedule an immediate timer.

Did you trace this behaviour by any chance?

+bug
+AppKit
+#needs-test

[cappbot]

Milestone: Someday. Labels: #new, AppKit, bug. What's next? A reviewer should examine this issue.

[ahankinson]

-#new

[cappbot]

Milestone: Someday. Labels: AppKit, bug. What's next? A reviewer should examine this issue.

[cappbot]

Milestone: Someday. Labels: #needs-unit-test, AppKit, bug. What's next? This issue needs a volunteer to write and submit one or more unit tests execercising the changes and/or the relevant parts of the original problem.

[zittix]

The unit tests have been added.

[mrcarlberg]

@zittix @aljungberg What can be done to move this pull request forward?

[zittix]

On my end, everything looks good. I have added a manual test to cover the issue and the fix does indeed fix it.

[mrcarlberg]

I would love to hear more about what @aljungberg said above, from both of you. Is this the best solution to this problem?

[aljungberg]

I think if the part of a [CALayer runLoopUpdateLayers] which actually resolves the issue is just pumping the run loop, then a better solution might be to either A) just pump the runloop right then and there or B) pump it at a higher level when we're actually forgetting to do so. But I can't say which is right, just speculating. A simple experiment would be to set a breakpoint on L1006 and check who called this method. If it looks like it is their responsible to pump the runloop, then do it there, otherwise do it on L1006.

[mrcarlberg]

@zittix Can you test the approach @aljungberg suggested?