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

Re: [go-nuts] Writing bitmap data to a canvas with WebAssembly

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,

[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

[go-nuts] [security] Go 1.21.4 and Go 1.20.11 are released

Hello gophers, We have just released Go versions 1.21.4 and 1.20.11, minor point releases. These minor releases include 2 security fixes following the security policy : - path/filepath: recognize \\??\\ as a Root Local Device path prefix. On Windows, a

[go-nuts] Re: Why golang's garbage collector didn't free obj when an finalizer is associate with it？

On Tuesday, November 7, 2023 at 2:32:28 AM UTC-5 Jan wrote: Btw, I don't follow the sentence: "the GC necessarily has to keep referents of the object-to-be-finalized live even if the object isn't referenced anymore" That is true for objects not in cycles that need to be finalized as well.

[go-nuts] Re: Why golang's garbage collector didn't free obj when an finalizer is associate with it？

I can completely understand the logic behind not freeing the objects with unclear ordering. But I expected that there will be some kind of upper limit / workaround for these kind of objects. But this means that using SetFinalizer on a big object, carelessly, can potentially lead to memory