-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve web backend performance by using inkwasm #2803
Comments
On the basis of this article the calls between JS and Wasm should be fast. |
It is sadly the other way around, call from wasm->js with a lot of data passed on those call. I am hoping that the work to support wasi might actually improve the way the go compiler and runtime actually cross that barrier. This way we wouldn't have to do anything about it. |
I see it's the first bar of the article. Yes, direct calls to Web API from wasm would probably help. |
Yeah, reducing call will help a lot too. That would help for embedded devices too (grouping all call that use the same shader to be one call of there is no collision with any other surface), reducing the use of buffered rendering (less call doing switches on web and less costly switch on embedded target). I would think that and a better wasm->js we would have some good/usable performance. There is still the issue of the lack of thread which impact the latency and scheduling of goroutine which might get solved at some point if we get thread support in the web assembly backend itself. There is a long road for this to be well supported, but I don't think it is impossible. We just need to do small step in that direction. |
What do you exactly mean with grouping calls to the same shader? Grouping the same shapes to one shader? |
Example 1 is the easiest and what I have in mind in the mid term (right now each is buffered, so there will be less benefit). |
JS-Runtime is single threaded in opposite to Go. JS uses 'async' (promise/future) a lot for non blocking operations (eg http request ...) to not freeze the ui. What does this mean for Fyne rendering in the browser? Is Fyne communicating between Wasm and Js in an async way or does the rendering process in the browser block the Js-Runtime until the rendering is finished or the data are submited over Js to the GPU?. So, if the event queue is alway blocked by the rendering process of the GL-Canvas, this would be I think the main drawback of the Web driver (Go-Wasm-Implementation) and as you mentioned the grouping of shapes would not improve the performance a lot. If the communication Go-Wasm-> Js and Js -> Go-Wasm happens synchronous this would explain the visible behaviour in the browser. |
To my understanding, right now go does not use wasm thread at all and the js and wasm runtime share the same thread. And yes, communication is also synchronous, but considering everything is just one thread, it just a traffic jam anyway. |
Is there something similar in Go on the way? dotnet/runtime#68162 |
Not to my knowledge :-( But there is more activity on the go wasm port now... |
Is your feature request related to a problem? Please describe:
A significant source of slow down for the webgl/wasm is the copy of data between the JS side and the Go side. Quite an important scenario for Fyne that upload a lot of data.
Is it possible to construct a solution with the existing API?
No new API should be introduced.
Describe the solution you'd like to see:
A potential solution would be to use a custom replacement for syscall/js as provided by https://github.com/Inkeliz/go_inkwasm .
The text was updated successfully, but these errors were encountered: