GrContext may be getting retained after rasterizer teardown on Android

[dnfield]

Internal customer testing suggests that Skia's resource cache is not getting purged on rasterizer teardown. I would expect this to happen because the GrContext is getting destroyed.

Need to determine whether the GrContext is actually getting destroyed or not, and then determine whether we just need to add a resource cache cleanup in teardown.

[dnfield]

xref b/234905381

[jason-simmons]

The rasterizer (via the surface_) typically holds a reference to the main GrDirectContext.

But there is also the resource GrDirectContext held by the ShellIOManager which is part of the same share group. And now the SkiaUnrefQueue also holds a GrDirectContext reference.

The PlatformView subclass may also hold a GrDirectContext reference. There is additional complexity if the app is using engine groups with a shared graphics context.

So shutdown of the rasterizer alone is insufficient to delete the GrDirectContext.

Ideally I'd like to be able to run the affected app with a local engine build and understand its lifecycle.

[dnfield]

Running the app is difficult and requires specialized hardware unfortunately.

I'm starting to think that we should just purge GrContext resources on rasterizer teardown, but I'm not sure I understand the impllications of that for multiple engines fully.

@gaaclarke

[gaaclarke]

Running the app is difficult and requires specialized hardware unfortunately.

I'm starting to think that we should just purge GrContext resources on rasterizer teardown, but I'm not sure I understand the impllications of that for multiple engines fully.

@gaaclarke

So the lightweight engines will be sharing a raster thread if they are sharing the same GrContext. So it is safe from that perspective. The code should build up resources that are no longer available since that should mimic low memory situations and the first run. It's possible we aren't covering all the cases there but those I would consider bugs even for the one engine situation.

[dnfield]

@jason-simmons - I don't think we have to worry about the IO context, since that one is getting purged periodically with a delay of zero and has no resource cache anyway.

[xster]

@jason-simmons I can try to answer some of the lifecycle events from memory if it helps

[github-actions]

This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.