News for hackers. Stuff that matters.

Schampu

Re:Is WebAssembly magic performance pixie dust? on Wednesday April 14, 2021 @04:12AM (#26804351)
This unfortunately introduces a lot of overhead and doesn't scale well for larger applications. WebGL calls are already incredibly slow compared to native, and the trampolining between WASM and JS world adds on top.

When WASM got released (around 2017), there was already that discussion to allow direct bindings without a JS roundtrip, but AFAIK there is still no actual implementation for this in any browser.

Re:Is WebAssembly magic performance pixie dust? on Wednesday April 14, 2021 @03:32AM (#26804084)
AssemblyScript initially targeted TS->WASM compilation, by only supporting a strict subset of the TS language. But at some point they dropped that idea and defined their own TS-like language. I don't know the reason for this, but my guess is that TS is too dynamic to just directly compile it to WASM?
Re:Copyright infringement by German contact tracing app on Wednesday March 31, 2021 @06:41AM (#26645606)
Regarding Germany's official Corona tracing app (not the of this post), by the end of last year there was a discussion about collecting movement data of the app users [0]. The discussion was part of the "German Infection Protection Act", resulted in public protests and in the end got declined. I wonder what the state of this is in other countries?

[0] https://www.sciencemediacenter.de/alle-angebote/rapid-reacti...

For example reverse engineering and parsing binary file formats
There is a WebKit based HTML renderer called Ultralight. It works by creating hooks and intercepting the rendering calls of WebKit in order to allow embedding it easily.

Unfortunately the license of Ultralight is questionable, and it's not open-source either by bypassing the WebKit license (which is very questionable as well since WebKit itself is BSD-licensed).

Having such a project as a free open-source variant would be a huge game changer in my opinion.

Re:Real-Time Ray-Tracing in WebGPU on Tuesday January 14, 2020 @04:54PM (#22049634)
Hey thanks for you comment.

The Ray-Tracing Extension is currently only available for Windows and Linux.

My next plan is to implement the extension into Dawn's D3D12 backend, so I can build chromium with my Dawn fork and have Ray-Tracing available directly in the browser (at least for myself) :)

Changed the title:)
Re:Show HN: RTX Real-Time Ray Tracing in JavaScript on Monday March 25, 2019 @12:00PM (#19483682)
Vulkan has a very verbose setup phase, but after that you only make some tiny calls here and there (Draw a frame, update some UBOs), so the CPU load isn't that high because you record most things at start-up.

Multi-threading is possible with SharedArrayBuffers [0] and N-API allows to take the memory address of it. NVK is only a thin layer above Vulkan and JavaScript <-> C++ interopability is pretty fast. You only notice some overhead when making thousands of calls, because the C++ code cannot be inlined. But again, this is not something common in Vulkan.

Also JavaScript doesn't have essential features like Compute shaders for years now. Vulkan has all of it. Even though WebGPU [1] is in development, I don't expect it to give access to the Vulkan RTX pipeline anytime soon.

[0] SharedArrayBuffer: https://v8docs.nodesource.com/node-4.8/d4/db8/classv8_1_1_sh...

[1] WebGPU: https://github.com/gpuweb/gpuweb

I think this depends on the type of the product. It's important that the team allows and finds the right spot to restart with more focus on architecture and code quality to not loose motivation of later employees
DataView [0] itself already has pretty useful methods to work with binary data. To encode/decode strings, use TextEncoder [1]

Both implementations are very optimized and fast. Also DataView offers working with 64-bit values using the new BigInt type [2].

Here [3] a short example on how you can quickly build C-like structures in JavaScript

[0] DataView: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

[1] TextEncoder: https://developer.mozilla.org/en-US/docs/Web/API/TextEncoder

[2] BigInt: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

[3] C-like Structures: https://jsfiddle.net/5tz0hsjq/

or just B1=B1
Re:BigInt: Arbitrary precision integers in JavaScript on Friday November 09, 2018 @07:53AM (#18414002)
I use them in a Vulkan API for node.js to handle 64bit interopability when mapping Vulkan memory. Mapping Vulkan memory returns you a numeric address to the memory region. To handle the address I use BigInt, which can then be used to create an ArrayBuffer as a direct JS-side memory view where you can write e.g. your texture data into. See [0] how its used on node-side and [1] the C++ implementation using the V8 API

[0] https://github.com/maierfelix/node-vulkan/blob/master/exampl...

[1] https://github.com/maierfelix/node-vulkan/blob/master/genera...

Older »