How can I "punch out a hole" in a scrollable view's background with the view's content?

I know that probably sounds weird, but let me explain.

I have a scroll view with custom shapes that are dynamically sized. The goal is to have some of those shapes, the ones on one side of the scroll view, basically be see-through to reveal the contents of a large gradient underneath. Therefore, as the shapes scroll up or down the view, their background would change as they move over the gradient.

However, the rest of the scroll view, including the other shapes and the blank areas in between, should not be see-through but instead have the default system background color. The other issue I've run into is that the gradient must not be visible until content is loaded in so you don't see the gradient flash in the little in-between time.

Currently, I have the scroll view itself having the gradient as the background. With a combination of adjusting my shapes to use even/odd filling, making my see-through shapes transparent, and adding "background covers" on all sides of the shapes, I almost have the desired results.

Problems:
The background is exposed when the list is dragged down.
The gradient does not continue off the screen, so the see-through messages disappear before the opaque messages. This is especially problematic for the production environment because of semi-transparent bars on the top and the bottom, meaning I can't extend the gradient unless I keep it covered in the safe areas.
In production, the scroll view content does not load immediately but has an opacity transition on appear. So, the gradient flashes as the content loads.

2 and 3 I may be able to tinker with and find a solution. I haven't spent much time trying yet. But, I'm thinking I may be approaching this problem in a less-than-optimal way. The ideal situation would be to have a gradient the size of the device height that is only visible through a particular view on top of it while being unexposed in all other situations.

Here's a brief code example.

Also, I considered actively calculating the gradient's appearance on the shapes as they scroll based on their scroll position, but my gut tells me performance will be an issue with that.