Geometry processing that's more complex than moving vertices around has to be done on the CPU for now.
Have you heard about our lord and savior abstract vector spaces?
everything is just moving vertices around in linear transformations.
We published this benchmark to have a public indicator of the performance gains WebAssembly promises in a real-world product.
One bit of constructive feedback: add a date of publishing to the article. PSPDFKit already has multiple articles on WASM before, and it's nice to be able to tell which one is the most "up to date" at a glance.
They just recently shipped it on Linux with V8 v6.8, but the Windows implementation is still a work in progress.
Firefox Nightly: 2216
Chrome Canary: 5078
Safari Tech Preview 60: 7216
Moto G4 phone Chrome: 37735
Windows 10 Laptop:
Firefox Nightly: 2278
Chrome Canary: 4907
Firefox Nightly: 7874
Google Chrome: 10602
The performance difference to native is smaller than you might think though - see our post from a few months back: https://pspdfkit.com/blog/2017/webassembly-a-new-hope/
PSPDFKit for Web Standalone is a great choice for an easy-to-deploy web viewer, annotation editor and form filler, and performance is great. Definitely better than pdf.js - which is typically where people start with, before they upgrade to PSPDFKit for Web.
...what. why would I want that over a library that I can do whatever I want with?
Also why would I want to download an entire pdf engine when i already have an AOT version? (Stealing that phrasing by the way :) )
It's also quite basic when it comes to forms and often loses data.
For cases where more performance is required we always recommend using PSPDFKit Server, so PDFs render in native code on a high-power machine, and very likely using cached tiles.
I never asked for that though, so there's that.
Most native OpenGL apps run in a spin loop as in
Of course if you decide to use a `gl.commit` spin loop your worker can no longer receive events (no onmesagge, no XHR, no websockets, no fetch) so you're supposed to use SharedArrayBuffers to communicate with a spin loop worker.
SharedArrayBuffers are being re-enabled once they are isolated to same domain only processes.
AFAICT this is the first browser API that is really targeted exclusively at WebAssembly. I'm guessing more will come. Not entirely sure how I feel about that but I guess it's inevitable.
What is TPTB?
SIMD is another WebAssembly only API, hopefully coming soon.
That blog post you linked to is 2 years old and out of date with what browser are actually planning on shipping.
For JS you no longer need commit at all. canvas (both 2d and webgl) work offsrcreen just like they do without offscreen. You render, when your event exits the changes get magically propagated to the corresponding canvas. commit is solely for when your event never exits (you're in a spinloop)
Any chance you can talk about those bottlenecks? Might be interesting.
I expected canvas rendering, which would be MUCH faster. (?)
<div style="top: 628.75px; left: 125px; position: absolute; transform-origin: 0px 0px 0px;"><label style="width: 38px; height: 38px;" class="PSPDFKit-43pb73xrbckjuggksebahxjw9 PSPDFKit-Annotation-Widget PSPDFKit-Annotation-Widget-CheckBox"><input name="Checkboxes 2" value="Checkboxes" type="checkbox"><span class="PSPDFKit-v4b9qprfhz2hybx1p43s4xgx6 PSPDFKit-8vpzte5r65p8pf9q4d61qcb34u" style="border-width: 1.25px;"></span></label></div>
Also (as far as I know) canvas content is inaccessible to screen readers. Accessibility matters.
Sounds like a great idea for encouraging performance improvements and avoiding regressions!
I see everything is through a sales person now and I'd like to get a better high level understanding of high level costs for passion projects (<1000 users), small-medium (<100k), and enterprise (1M+). What metrics are you charging usage on?
From https://twitter.com/steipete/status/1013035117076467713 :
Shoutout to the Safari team! They were able to track down the slowness in the current WebAssembly implementation and ALREADY FIXED IT. Patch is here: https://trac.webkit.org/changeset/233378/webkit
(trace points caused a significant (4x!) slowdown as our benchmark performs many calls into the VM)
In a sense, it would be like a JIT for the Web, and one possibility for bringing existing JIT-based languages to WASM.
A similar question would be "What languages do you know of that are focused on performance and compiling to wasm?" For that, I'd say C++, Rust, and Go, though I'm sure there are others.
There's also the question of what aspect of performance is of interest to you. Do you include the download time in performance? If so, languages that produce leaner wasm files will be better performing, even if the execution is identical. Do you only care about execution time? Then that aspect isn't relevant. etc.
So, do not expect a clear answer to that questions. Probably no one really knows because of a lack of benchmarks and deployments in the wild that have been analyzed. That's why they made the benchmark.
This is very vague, but already disturbing
Yeah, god forbid the platforms gets more powerful...
Many were quick to criticize Valve and Epic about their own criticism of the Microsoft Store, which is why Microsoft is now using a "boiling the frog" strategy to tie everything to the Store over the next decade or so. And this process will likely accelerate once Windows 7 is dead and buried.
Microsoft has picked up on Google's PWA ideas and is migrating UWP hosted web apps to it.
I expect Google to follow a similar path with Android and ChromeOS.
- Chromium 68: 5722
- Safari 11.1.1: 6500
On 2017 Macbook pro running macOS 12.13.5 on battery power