CAContext-based cross-process CALayer APIs appear to be broken in 10.12 |
||||||
Issue descriptionThis came up in the course of investigating issue 633805 . Consider the attached program color-remote-layer.mm. On 10.9-10.11, the remote window and the local window matched each other. Starting in 10.12, the application no longer works -- the remote window is blank. The interface that this uses for remote layers is the CAContext-based API. Of note is that if the CAContext API is used locally within the same process, it does work (see the attached color-remote-layer-local-only.mm). The reason for this behavior breaking is unknown. It may be that the API is still fully supported but has additional security restrictions that prevent this particular demo from working. Or it may be that the API is deprecated and Chrome is on a "do not break" list and getting special treatment. We should either find why this is happening or get off of using the remote layer path (or both).
,
Jan 23 2017
10.12 breaks this particular app using the API The SDK version isn't so important, because this isn't a public API Somehow, Chrome doesn't break when using the API. I have a suspicion that it may have to do with how we spawn our processes, or a whitelisting from Apple.
,
Jan 24 2017
OK, thanks for the info. So is the plan to not ask Apple about it? If so, that means our plan is to get off of this API - what is involved with that?
,
Jan 27 2017
I prototyped this in https://codereview.chromium.org/2473973002/, but it's not clear if it's worth changing things (cause stuff always breaks).
,
Mar 16 2017
I was playing with CAContext in a test app and found this crbug. It works for me (but I'm using XPC instead of fork). Demo attached. It's in a hacky state because I was working on using fence ports to synchronize resizing and haven't nailed it down, and just ripped that part out.
,
Mar 16 2017
After looking today at Issue 665201 , I'm wondering if our use of this broken API is the culprit. ccameron@ - would it make sense to land your change in c#4 as an experiment so that we can see what differences it makes?
,
Mar 17 2017
Oh, that's a good point -- maybe XPC instead of fork is the key. Some things would get nicer with the removal of remote layers, but some things may get worse. I think it's worth doing, but behind a Finch experiment.
,
Mar 17 2017
Fork+exec might also work — I seem to remember rsesek@ taking about how some macOS APIs break in unexpected ways after a fork alone.
,
Mar 17 2017
Agree, behind a Finch experiment.
,
May 3 2017
Btw, the change in #4 is part of the bigger scheme in issue 604052. |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by shrike@chromium.org
, Jan 23 2017