You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Flutter GPU] Discovery: Is Flutter GPU's rasterization workflow safe? #150816
For this discovery, document whether it's possible for a renderer written against Flutter GPU to perform unsafe behavior.
"Safe" in this context means:
No crashes.
No memory corruption.
No Metal/Vulkan validation failures.
Example of valid API usage which is not considered "unsafe":
The user creates a new Flutter GPU Texture and draws it to the screen without first clearing it, causing uninitialized garbage to display.
Currently, Flutter GPU's usage flow for rasterization works like this:
Get the GPU context.
Create a CommandBuffer with GpuContext.createCommandBuffer.
Create a RenderPass with CommandBuffer.createRenderPass.
Set state/pipelines and bind resources with various RenderPass methods.
Append draw commands with RenderPass.draw.
Submit the CommandBuffer with CommandBuffer.submit (async). All RenderPasses are encoded in the order with which they were created.
Things to check:
Is accessing the Flutter GPU context from a separate isolate currently safe? Should we detect/restrict this?
RenderPasses are currently always enqueued in the same order with which they were created, but CommandBuffers may be explicitly submitted in any order. Verify that differing the CommandBuffer submission order from the CommandBuffer creation order results in predictable and safe behavior.
I don't believe that APIs like HostBuffer are thread safe. For isolate usage, I'd wonder if you could even send the native objects across isolates. For example, maybe I have a worker spin up to encode some work that renders to a texture. But then if I can't get that texture object back to the main thread, I have no way to actually present it. If there are restrictions like that, then preventing usage in other isolates is more of a matter of frustration prevention.
I don't believe that APIs like HostBuffer are thread safe.
I don't think there would be any way for a user to reference the same shared buffer or Texture resources across different isolates (unless I missed something obvious w/ how isolates work 🤣).
But then if I can't get that texture object back to the main thread, I have no way to actually present it. If there are restrictions like that, then preventing usage in other isolates is more of a matter of frustration prevention.
Yeah I'm not sure how useful it would be to even support running it in multiple isolates right now... Theoretically you could e.g. myTexture.asImage().toByteData() and pass the bytes back, but not yet sure if that's safe.
I think we should still get around to checking the couple of things I listed here. We're in the process of reviving Flutter GPU and will keep this open as a discussion thread for the moment.
Activity
jonahwilliams commentedon Jun 26, 2024
I don't believe that APIs like HostBuffer are thread safe. For isolate usage, I'd wonder if you could even send the native objects across isolates. For example, maybe I have a worker spin up to encode some work that renders to a texture. But then if I can't get that texture object back to the main thread, I have no way to actually present it. If there are restrictions like that, then preventing usage in other isolates is more of a matter of frustration prevention.
bdero commentedon Jun 26, 2024
I don't think there would be any way for a user to reference the same shared buffer or Texture resources across different isolates (unless I missed something obvious w/ how isolates work 🤣).
Yeah I'm not sure how useful it would be to even support running it in multiple isolates right now... Theoretically you could e.g.
myTexture.asImage().toByteData()and pass the bytes back, but not yet sure if that's safe.mbcorona commentedon Mar 4, 2026
Since the PR #150828 is closed, should this issue be closed as well?
bdero commentedon May 1, 2026
I think we should still get around to checking the couple of things I listed here. We're in the process of reviving Flutter GPU and will keep this open as a discussion thread for the moment.