typometer VS gpuweb

You can download the tool here: https://github.com/pavelfatin/typometer

Thanks, that's a really nice offer. Well, if your pi can run typometer that would be an ideal thing to test. Use an editor that has good typing latency. That is nothing based on electron or java. Geany or Kate should work. Don't use vim or emans on a terminal as most terminals have terrible typing latency (except xterm and mlterm)

Typometer with 200 characters

There is a great comparison between various terminals' latency https://danluu.com/term-latency/ (it comes up periodically on HN too - https://news.ycombinator.com/item?id=19443076), so once when I was curious if it was just me or if RDP was indeed slower, I did a quick test using the same toolset - https://github.com/pavelfatin/typometer

It is not a super-scientific test since:

0) I didn't spend too much time on this

open -a Spotify --args --disable-smooth-scrolling

You used to be able to disable Chrome's smooth scrolling with chrome://flags/#disable-smooth-scrolling, but that flag was removed for whatever reason.

I'm also surprised by how much faster Firefox's builtin middle mouse click autoscroll is compared to Chrome's ersatz AutoScroll[2] extension.

[0]: https://download.developer.apple.com/Developer_Tools/Additio...

[1]: https://pavelfatin.com/typometer/

[2]: https://chrome.google.com/webstore/detail/autoscroll/occjjkg...

First, about the methodology: I took all my measurements with typometer on an Ubuntu 18.04 computer running X11. I tried Firenvim (both in Firefox and Chrome), Fvim, Gnvim, Goneovim, Neovim-Gtk, Nvim-Qt, Nwin and Uivonim. I couldn't try Neovide because it didn't run on my computer. The terminal I tried was Kitty, which has better latency than Alacritty.

The first thing to do is to try and measure latency to confirm your feeling. You can use something like typometer ( https://github.com/pavelfatin/typometer ) to do that.

People keep spreading this incredibly misleading statement, and yours is even more misleading (suggesting Apple opposed a 'GPU WASM')

By all accounts, Apple's /only/ stance was that if WebGPU used SPIR-V it would be a non-starter for them, due to ongoing legal issues between Apple and Khronos.

Apple actually proposed WebHLSL in collaboration with Microsoft, to have HLSL be the standard.

Mozilla employee's stance[0] was that SPIRV was too low level, did not fit with the goals of WebGPU portability and security, and expressed concern that Khronos may add functionality to SPIRV they cannot support in WebGPU like raytracing instructions .. 'So we'd always be on the verge of forking SPIR-V in some way.'

It was also noted by many people that even if a bytecode format was used, it would still have to be translated to the target (HLSL/DXIL, MSL, etc.) in almost the same way a text format would.

Nobody proposed a 'GPU WASM equivalent' or an alternative bytecode format.

The hard truth is that shader compilation is a fucking nightmare, people do not realize how bad it is across the different native APIs. SPIR-V is good, but it doesn't solve that - and presents other challenges if you are a web browser API. Vulkan and SPIRV are not the golden goose many make them out to be.

[0] https://github.com/gpuweb/gpuweb/issues/847#issuecomment-642...

Yes it is still a bit new. WebGPU is not finished and is still being worked on: https://webgpu.io/

WebGPU currently doesn't support the "bindless" resource access model (see: https://github.com/gpuweb/gpuweb/issues/380).

The "max number of sampled texture per shader stage" is a runtime device limit, and the minimal value for that seems to be 16. So texture atlasses are still a thing in WebGPU.

There's even an implementation under discussion to have the dp4a instruction added to WebGPU (https://github.com/gpuweb/gpuweb/issues/2677)