Improve web backend performance by using inkwasm

[Bluebugs]

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 .

[renlite]

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]

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]

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]

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]

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]

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]

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]

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]

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

[Bluebugs]

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