1

I'm trying to create a view hierarchy similar to what you'd expect in a media playback viewer like the QuickTime Player:

+ Host View
  + Video Controls (NSView layer-backed)
  + Video View (NSView layer-hosted)
    + AVPlayerLayer

Since layer-hosted views cannot contain subviews, the video controls view is a sibling of the video view and simply ordered-front so that it's on top of the video view.

This current view hierarchy appears to be working fine for me, but I remain a bit confused over whether it's officially "supported" because of the overlapping, sibling views (the video controls view always overlaps the video view).

This Stack Overflow question: Is there a proper way to handle overlapping NSView siblings? offers conflicting information regarding overlapping sibling views.

I would assume the more 'correct' way to handle this is for the video controls to be a subview of the video view, which is only possible of I change the video view from being a layer-hosted view to a layer-backed view.

By default a layer-backed view uses a basic CALayer as its backing store, but NSView exposes makeBackingLayer to allow you to return a custom layer such as an AVPlayerLayer.

By doing that, and moving the controls view to be a subview of this layer-backed video view, things also appear to work properly but now there's an AVPlayer object that is directly modifying the contents of the AVPlayerLayer. That seems to be contrary to the requirement that in a layer-backed view, you should never modify the contents of the layer without going through the NSView using something like drawRect or updateLayer.

This seems to leave me with two choices, neither of which appears 'correct' based on my interpretation of the document:

Option 1:

  • Layer-hosted view for the AVPlayerLayer
  • Overlapping sibling view for the controls view.

Option 2:

  • Layer-back view with an AVPlayerLayer via makeBackingLayer
  • AVPlayer that directly modifies the contents of the AVPlayerLayer
  • Controls view as a subview of the video view

I'm inclined to think that option #2 is the more correct way and that in this scenario, it's OK for the AVPlayer to directly modify the contents of the AVPlayerLayer even though it's in a layer-backed view, but I'm not certain and would be curious if others have any thoughts or experiences with a setup like this.

Community
  • 1
  • 1
kennyc
  • 5,490
  • 5
  • 34
  • 57

1 Answers1

1

Apple has some old (ancient in computer terms, 2007!) code that doesn't even compile in Xcode 6 without some tweaks. It shows some controls that are overlaying a QuickTime movie layer. Download it here: https://developer.apple.com/library/mac/samplecode/CoreAnimationQuickTimeLayer/Introduction/Intro.html .

It's hard to say that just because they provided source code that it's considered a best practice, but I would suggest you just build it the way you think is best. This is not one of those areas so heavily developed on that a best practice is likely to exist. For me personally it makes the most sense to use overlapping sibling views as to ensure that you don't mess with the video rendering. Whether that's the right way or not is probably somewhat subjective. You can maybe access one of the old quicktime developers mailing lists or even ask on the Apple developer forums. At the end of the day though you should probably just stick with the method that makes the most sense to you since you're likely to be the one to maintain or build upon it in the future.

Matt Long
  • 24,438
  • 4
  • 73
  • 99
  • Interesting, in the sample code they appear to be adding sublayers to a layer-backed view, which as far as I've been told has never been the "right thing" to do. In the end, I've opted to use `makeBackingLayer` because if you can't set the backing layer for an NSView to something other than a generic `CALayer`, then what's the point of `makeBackingLayer`? You might as well just use a layer-hosted view then for your custom `CALayer`, and layer-hosted views are definitely documented as not supporting subviews. Things seem to be working... Thanks for the input. – kennyc Apr 21 '15 at 20:51