Skip to content
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

Open
Bluebugs opened this issue Feb 23, 2022 · 10 comments
Open

Improve web backend performance by using inkwasm #2803

Bluebugs opened this issue Feb 23, 2022 · 10 comments
Labels
Driver:web Issues related to web driver specifically enhancement New feature or request

Comments

@Bluebugs
Copy link
Contributor

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 .

@Bluebugs Bluebugs added enhancement New feature or request Driver:web Issues related to web driver specifically labels Feb 23, 2022
@Bluebugs Bluebugs added this to the Bowmore Release (early 2022) milestone Mar 11, 2022
@andydotxyz andydotxyz removed this from the Bowmore Release (early 2022) milestone Jun 3, 2022
@renlite
Copy link
Contributor

renlite commented Jan 21, 2023

On the basis of this article the calls between JS and Wasm should be fast.
https://hacks.mozilla.org/2018/10/calls-between-javascript-and-webassembly-are-finally-fast-%F0%9F%8E%89/
Does the compiled Go code to Wasm handle the calls of Js function in different way?

@Bluebugs
Copy link
Contributor Author

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.

@renlite
Copy link
Contributor

renlite commented Jan 21, 2023

I see it's the first bar of the article. Yes, direct calls to Web API from wasm would probably help.
I turned off the rendering of textures and started /cmd/fyne_demo in the browser for tests. The demo app was more responsive then but not as performat as on desktop.

@Bluebugs
Copy link
Contributor Author

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.

@renlite
Copy link
Contributor

renlite commented Jan 21, 2023

What do you exactly mean with grouping calls to the same shader? Grouping the same shapes to one shader?
Example 1: Menu of 10 Buttons on the screen. These buttons have the same properties. The vertex coords will be send in one array/call (eg. 20 x triangles) to the GPU and the fragment shader would render all 10 Buttons/rectangles in one. In this case the Walktree would have to collect the same shapes and call a render func for all shapes of the same type.
Example 2: Bringing the animation from CPU to fragment shader of the GPU.

@Bluebugs
Copy link
Contributor Author

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).

@renlite
Copy link
Contributor

renlite commented Jan 22, 2023

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.

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.

@Bluebugs
Copy link
Contributor Author

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.

@renlite
Copy link
Contributor

renlite commented Jan 25, 2023

Is there something similar in Go on the way? dotnet/runtime#68162

@Bluebugs
Copy link
Contributor Author

Not to my knowledge :-( But there is more activity on the go wasm port now...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Driver:web Issues related to web driver specifically enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants