How to control the SkImage GPU back cache size?

21 views
Skip to first unread message

Jona

unread,
May 26, 2021, 11:03:48 AMMay 26
to skia-discuss
I'm not sure where I saw that SkGraphics::SetResourceCacheTotalByteLimit() was possibly used for specifying the SkImage GPU cache.

As far as I understand when I load SkImage from file or SkBitmap the SkImage lives in CPU side memory. Then the moment I draw this SkImage on a GPU backed canvas it will make a copy of the CPU data into a GPU backed texture. So now we technically have two copies available on the SkImage. Then each time I draw that SkImage it will do it quickly cause it's already in the GPU side.

I'm trying to understand if I can monitor or control the cache size of GPU backed textures? Is this even something I need to worry about?

Thanks!
- Jona

Brian Salomon

unread,
May 26, 2021, 1:15:38 PMMay 26
to skia-d...@googlegroups.com
Hi Jona,

You are correct that SkImages that are backed by pixels (or an encoded image) are cached as textures on the GPU. The budget for this is controlled by GrDirectContext::setResourceCacheLimit(). And you're also correct that you now have two copies. If the texture copy gets purged and you redraw the image then it gets recreated.

Alternatively, you can call SkImage::makeTextureImage(). This will return a new SkImage that is backed by a texture that is explicitly owned by the SkImage. The texture's lifetime is tied to the SkImage, i.e. it won't get purged under memory pressure. You can control whether the texture's memory counts against the context's memory budget with the SkBudgeted parameter.

Brian

--
You received this message because you are subscribed to the Google Groups "skia-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to skia-discuss...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/skia-discuss/ff65fae4-95a3-4206-90c1-b7b0f9da1a39n%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages