[go-nuts] Cogent Core, a cross-platform GUI framework in Go
Hello Gophers, Today we are announcing the initial public release of the Cogent Core GUI framework. Cogent Core allows you to build powerful, fast, elegant apps that run on all platforms with a single Go codebase, allowing you to Code Once, Run Everywhere (Core). We encourage you to check out our blog post <https://cogentcore.org/blog/initial-release>, which is an interactive Cogent Core app running on the web. Cheers, Kai O'Reilly and Randy O'Reilly -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/ff001af5-7206-4bdf-8008-15adf004776fn%40googlegroups.com.
Re: [go-nuts] Writing bitmap data to a canvas with WebAssembly
Apologies for any confusion I created. I was referring to the time spent
transferring the image from Go to JS and placing it on the canvas, not the
actual time it takes the browser to render the canvas, as the transfer and
placing time is the only thing that can be easily controlled.
On Tuesday, November 7, 2023 at 8:36:23 PM UTC-8 robert engels wrote:
> Your numbers do not make sense.
>
> At 300 us a frame, it would be more than 3k frames a second - which would
> only be possible for an extremely tiny area.
>
> You need to include the time to produce the data when considering “render
> time” - otherwise you are talking apples and oranges.
>
> On Nov 7, 2023, at 9:43 PM, Kai O'Reilly wrote:
>
> For future reference for anyone who comes across this thread, you can
> directly pass RGBA image data to a canvas, which is around 200 times faster
> than encoding it to a PNG and rendering it to an offscreen image. Also,
> passing the unsafe pointer to the slice to JavaScript instead of copying
> the bytes improves performance by another factor of 5. These two changes
> combined reduced the render time for me from roughly 300 milliseconds to
> 300 microseconds (a 1000x improvement). This performance is enough to run
> an interactive pure Go GUI through WASM without any noticeable lag, just by
> writing images to a canvas.
>
> This is the relevant Go code:
>
> ```go
> sz := dw.image.Bounds().Size()
> ptr := uintptr(unsafe.Pointer(&dw.image.Pix[0]))
> js.Global().Call("displayImage", ptr, len(dw.image.Pix), sz.X, sz.Y)
> ```
>
> And this is the relevant JS code:
>
> ```js
> const appCanvas = document.getElementById('app');
> const appCanvasCtx = appCanvas.getContext('2d');
>
> let wasm;
> let memoryBytes;
>
> // displayImage takes the pointer to the target image in the wasm linear
> memory
> // and its length. Then, it gets the resulting byte slice and creates an
> image data
> // with the given width and height.
> function displayImage(pointer, length, w, h) {
> // if it doesn't exist or is detached, we have to make it
> if (!memoryBytes || memoryBytes.byteLength === 0) {
> memoryBytes = new Uint8ClampedArray(wasm.instance.exports.mem.buffer);
> }
>
> // using subarray instead of slice gives a 5x performance improvement
> due to no copying
> let bytes = memoryBytes.subarray(pointer, pointer + length);
> let data = new ImageData(bytes, w, h);
> appCanvasCtx.putImageData(data, 0, 0);
> }
> ```
> In the JS code, `wasm` is initialized as the result of
> `WebAssembly.instantiateStreaming`.
>
> On Friday, July 24, 2020 at 10:53:14 AM UTC-7 Mark Farnan wrote:
>
>> Little old, but this might also help.
>>
>> A while back I built a helper package to deal with these issues for
>> canvas rendering from Go.
>>
>> https://github.com/markfarnan/go-canvas
>>
>> I'm currently working on it to add WebGL support & get it working in
>> TinyGo (some issues still).
>>
>> Regards
>>
>> Mark.
>>
>>
>>
>> On Sunday, 22 March 2020 at 09:08:40 UTC+1 Scott Pakin wrote:
>>
>>> I figure I ought to follow up with some results. First, I got the
>>> suggested approach of local render + js.CopyBytesToJS
>>> <https://golang.org/pkg/syscall/js/#CopyBytesToJS> + update canvas from
>>> image to work, so thanks, Agniva and Howard! Second, for the benefit of
>>> future readers of this thread, one thing that wasn't obvious to me is that
>>> one needs to render the image data in a browser-recognizable image format—I
>>> used PNG <https://en.wikipedia.org/wiki/Portable_Network_Graphics>—*not*
>>> raw {red, green, blue, alpha} bytes as is needed when writing directly to a
>>> canvas <https://www.w3schools.com/tags/tag_canvas.asp>'s image data.
>>> Third, I used JavaScript code like the following to update an invisible
>>> img <https://www.w3schools.com/tags/tag_img.asp> then copy the image
>>> data from there to a visible canvas:
>>>
>>> function copyBytesToCanvas(data) {
>>> let blob = new Blob([data], {"type": "image/png"});
>>> let img = document.getElementById("myImage");
>>> img.onload = function() {
>>> let canvas = document.getElementById("myCanvas");
>>> let ctx = canvas.getContext("2d");
>>> ctx.drawImage(this, 0, 0);
>>> };
>>> img.src = URL.createObjectURL(blob);
>>> }
>>>
>>> Fourth, the performance i
[go-nuts] Re: Writing bitmap data to a canvas with WebAssembly
For future reference for anyone who comes across this thread, you can
directly pass RGBA image data to a canvas, which is around 200 times faster
than encoding it to a PNG and rendering it to an offscreen image. Also,
passing the unsafe pointer to the slice to JavaScript instead of copying
the bytes improves performance by another factor of 5. These two changes
combined reduced the render time for me from roughly 300 milliseconds to
300 microseconds (a 1000x improvement). This performance is enough to run
an interactive pure Go GUI through WASM without any noticeable lag, just by
writing images to a canvas.
This is the relevant Go code:
```go
sz := dw.image.Bounds().Size()
ptr := uintptr(unsafe.Pointer(&dw.image.Pix[0]))
js.Global().Call("displayImage", ptr, len(dw.image.Pix), sz.X, sz.Y)
```
And this is the relevant JS code:
```js
const appCanvas = document.getElementById('app');
const appCanvasCtx = appCanvas.getContext('2d');
let wasm;
let memoryBytes;
// displayImage takes the pointer to the target image in the wasm linear
memory
// and its length. Then, it gets the resulting byte slice and creates an
image data
// with the given width and height.
function displayImage(pointer, length, w, h) {
// if it doesn't exist or is detached, we have to make it
if (!memoryBytes || memoryBytes.byteLength === 0) {
memoryBytes = new Uint8ClampedArray(wasm.instance.exports.mem.buffer);
}
// using subarray instead of slice gives a 5x performance improvement due
to no copying
let bytes = memoryBytes.subarray(pointer, pointer + length);
let data = new ImageData(bytes, w, h);
appCanvasCtx.putImageData(data, 0, 0);
}
```
In the JS code, `wasm` is initialized as the result of
`WebAssembly.instantiateStreaming`.
On Friday, July 24, 2020 at 10:53:14 AM UTC-7 Mark Farnan wrote:
> Little old, but this might also help.
>
> A while back I built a helper package to deal with these issues for
> canvas rendering from Go.
>
> https://github.com/markfarnan/go-canvas
>
> I'm currently working on it to add WebGL support & get it working in
> TinyGo (some issues still).
>
> Regards
>
> Mark.
>
>
>
> On Sunday, 22 March 2020 at 09:08:40 UTC+1 Scott Pakin wrote:
>
>> I figure I ought to follow up with some results. First, I got the
>> suggested approach of local render + js.CopyBytesToJS
>> + update canvas from
>> image to work, so thanks, Agniva and Howard! Second, for the benefit of
>> future readers of this thread, one thing that wasn't obvious to me is that
>> one needs to render the image data in a browser-recognizable image format—I
>> used PNG —*not*
>> raw {red, green, blue, alpha} bytes as is needed when writing directly to a
>> canvas 's image data.
>> Third, I used JavaScript code like the following to update an invisible
>> img then copy the image
>> data from there to a visible canvas:
>>
>> function copyBytesToCanvas(data) {
>> let blob = new Blob([data], {"type": "image/png"});
>> let img = document.getElementById("myImage");
>> img.onload = function() {
>> let canvas = document.getElementById("myCanvas");
>> let ctx = canvas.getContext("2d");
>> ctx.drawImage(this, 0, 0);
>> };
>> img.src = URL.createObjectURL(blob);
>> }
>>
>> Fourth, the performance is indeed substantially faster than my previous
>> approach based on using SetIndex
>> to write directly to
>> the canvas, even though the new approach requires the extra steps of
>> encoding the image in PNG format and copying the image data from an img
>> to a canvas. The following performance data, measured with Go 1.14 and
>> Chromium 80.0.3987.132 on an Ubuntu Linux system, is averaged over 10
>> runs:
>>
>> *Old*: 686.9 ± 7.6 ms
>> *New*: 290.4 ± 4.1 ms (284.3 ± 4.2 on the WebAssembly side plus 6.0 ±
>> 2.3 on the JavaScript side)
>>
>> This is the time to render a simple 800×800 gradient pattern.
>>
>> I hope others find this useful.
>>
>> — Scott
>>
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/267bc2d7-1e7a-4704-98cd-3c471fa0d19dn%40googlegroups.com.
