Any efficient way to pass the frame buffer to the WebView? #4177
-
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 19 replies
-
That's because Tauri chose Message Passing as it's IPC architecture not Shared Memory. We basically chose to trade performance in exchange for security. So shared memory for zero-copy data exchange is neither supported nor planned. But our current IPC system isn't perfect either, the bad performance with binary data is something we will be working on after v1 and while not zero-copy, I hope we can deliver performance comparable to WebRTC. |
Beta Was this translation helpful? Give feedback.
-
|
It's not zero-copy and maybe not even a very smart idea but what about a temporary (maybe memory-mapped) file to exchange the data? Both, the backend and frontend can read files so it should be possible. The question is: is it faster than message passing? I'm using Flutter right now and there I'm facing the same problem. I have video buffers and complex graphs that I want to render in real-time. Nothing too crazy. 30-60 fps. In Flutter it's possible (but very complex) to implement shared OpenGL/Vulkan/D3D/.. contexts and textures so the backend can render directly into those. But the amount of code needed to do so is crazy. Tauri sounds like a solid option for future projects. |
Beta Was this translation helpful? Give feedback.
-
How can the frontend read that file? |
Beta Was this translation helpful? Give feedback.
-
With this API if I understand correctly: https://tauri.app/v1/api/js/fs/ |
Beta Was this translation helpful? Give feedback.
-
|
This api uses the same message passing IPC under the hood. (same for all tauri apis btw) |
Beta Was this translation helpful? Give feedback.
-
|
In that case it doesn't make much sense, of course. Thanks for clarifying! |
Beta Was this translation helpful? Give feedback.
That's because Tauri chose Message Passing as it's IPC architecture not Shared Memory. We basically chose to trade performance in exchange for security. So shared memory for zero-copy data exchange is neither supported nor planned. But our current IPC system isn't perfect either, the bad performance with binary data is something we will be working on after v1 and while not zero-copy, I hope we can deliver performance comparable to WebRTC.