Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pay attention to WebAssembly

harshal.sheth.io

Post reply on HN
Print view View original

231–240 of 251 posts

Re: Pay attention to WebAssembly

#231

Post by riskneutral »

evmar wrote: post #62

> Figma makes use of a low-level C++ library called Skia for 2D graphics rather than building their own graphics engine This is not quite right. The bulk of Figma rendering is Figma-custom GPU code. It's true that Figma uses Skia, but only for some specific graphics algorithms in Skia, not as a general purpose rendering library. Source: I work on this code.

> The bulk of Figma rendering is Figma-custom GPU code. It's true that Figma uses Skia, but only for some specific graphics algorithms in Skia, not as a general purpose rendering library.

Can I ask why you went that route, instead of just using Skia?

Re: Pay attention to WebAssembly

#232

Post by hutzlibu »

codeflo wrote: post #226
hutzlibu wrote: post #213

Earlier quoted context omitted.

"WebAssembly only replaces the auto-updater part. " No, it replaces the need to install something on your computer. For trying out an unknown game, I rather have a sandboxed web application, than having to install something. And most who think more in terms of convenience, will prefer the non install solution, too. Installing new software is a big hurdle to many non technical people. I witnessed many children tears,…

Are you writing from theory, or from personal experience with game app stores? Because IMO, this is mostly a solved problem in practice with Steam, Epic Store, Windows Store etc. That’s partly why those platforms are so popular.

"Because IMO, this is mostly a solved problem in practice with Steam, Epic Store, Windows Store etc."

Erm. Yes, but wasn't your point that indie developers can market directly(without those plattforms) with ease right now?

"WebAssembly only replaces the auto-updater part. The actual value that Steam adds is discovery and trust"

Using webassembler brings in trust. Worried parents do not have to approve installing another unknown app.

Re: Pay attention to WebAssembly

#234

Post by 62951413 »

SquibblesRedux wrote: post #83

Reading the article, I felt like I was back in 1996 reading about the Java bytecode compiler and the JVM plugin for the browser. Java had such great promise for web page-hosted code, that would be portable, performant, and safe. Why would one think WebAssembly will succeed where Java failed? (Well, Java did not exactly fail, but its purpose and typical usage radically changed over the years.)

The parallels with the JVM are obvious on multiple levels.

In case of WASM I'm curious specifically about cross-language portability. We have learned from the JVM that while technically possible it may not be a popular choice. Java/Kotlin/Scala ecosystems diverged quickly.

So WASM could become a browser technology the way JVM became a strictly server-side thing. Or allow backend developers build frontend applications in a language they are used to.

On a related note, there's something funny about everyone stacking on top of each other. At some point Java will be probably compiled to WASM. You already can go in the other direction with https://www.graalvm.org/22.0/reference-manual/wasm/ . And GraalVM itself is designed to support a wide range of programming languages.

Re: Pay attention to WebAssembly

#235

Post by 62951413 »

chubot wrote: post #23

Cross-language interactions suck. We need WebAssembly components and good code generators for a critical mass of languages before people actually start to use Wasm across different languages. Unpopular opinion: Users will eventually realize that the lowest common denominator between languages is ... a BYTE STREAM (e.g. JSON/CSV/HTML), or what I think of as shell / Unix / Web -style composition. IDLs and code generato…

I always thought Java was the original protobuf library. Of the big three (PB, Avro, Thrift) only protobufs have a great modern RPC library included. I suspect more people start using PB because of gRPC. Unfortunately many people are still stuck with JSON over HTTP. I believe gRPC is more popular among systems where mobile clients dominate.

As a side note, if you expect to programmatically change your records (e.g. inject a new field on the server into a record received from a client) Avro is a much better choice. Avro also has a stronger schema migration story. But both are row-oriented formats with nearly identical IDLs anyway.

Re: Pay attention to WebAssembly

#236

Post by FractalHQ »

fxtentacle wrote: post #181
echelon wrote: post #129

Earlier quoted context omitted.

> What’s your point? Why you expect your Unreal-to-WASM product to succeed when Epic Games can simply build your entire product as a feature of the engine? You are building on their platform and not an open web stack, after all. Despite having an open web, most people have elected to use platforms. At some point, people will defer revenue for simplicity.

I think OP is working on the Epic team. They already have workable emscripten support in UE4

They officially dropped support for their web export. Even if you use the older version of the engine that did support it, mileage varies heavily.

Re: Pay attention to WebAssembly

#237

Post by evmar »

riskneutral wrote: post #231
evmar wrote: post #62

> Figma makes use of a low-level C++ library called Skia for 2D graphics rather than building their own graphics engine This is not quite right. The bulk of Figma rendering is Figma-custom GPU code. It's true that Figma uses Skia, but only for some specific graphics algorithms in Skia, not as a general purpose rendering library. Source: I work on this code.

> The bulk of Figma rendering is Figma-custom GPU code. It's true that Figma uses Skia, but only for some specific graphics algorithms in Skia, not as a general purpose rendering library. Can I ask why you went that route, instead of just using Skia?

I don't know the history, but I think Figma predates much public knowledge about Skia.

Further, I have the impression that Figma has pretty specific and complex graphics needs. For one example of the sort of thing I mean, we decode image data in JS and put it into GL textures without the Wasm side ever seeing the pixel data, so that the browser can (potentially) decode on a background thread and uncompressed pixel data doesn't contribute to Wasm heap memory usage. However, I don't know Skia well, so it's possible Skia has some mechanism to composite GL textures it's not responsible for too.

Re: Pay attention to WebAssembly

#238

Post by tekknik »

ncmncm wrote: post #210
fsloth wrote: post #128

Earlier quoted context omitted.

FWIW I think GPU is fine as Webgl is the only api browser can use before Webgpu takes off.

I wonder why we don't get WebVulkan instead. Is it just because Apple Metal is insufficient to implement Vulkan on?

Interesting the default to blame Apple, but OK

Re: Pay attention to WebAssembly

#239

Post by ncmncm »

tekknik wrote: post #238
ncmncm wrote: post #210

Earlier quoted context omitted.

I wonder why we don't get WebVulkan instead. Is it just because Apple Metal is insufficient to implement Vulkan on?

Interesting the default to blame Apple, but OK

We know that Apple does not expose a synchronization primitive needed for full Vulkan support. Apple could add such support to Metal any time they came to care enough. Anyway nobody else can.

Re: Pay attention to WebAssembly

#240

Post by nahumfarchi »

hansworst wrote: post #178
nahumfarchi wrote: post #156

Earlier quoted context omitted.

One thing that I was curious about, if I may ask, is how does Figma goes about font rendering?

Not sure if they use the same, but here's an article about text rendering from the CTO of Figma: https://medium.com/@evanwallace/easy-scalable-text-rendering...

Thanks, I actually remember seeing this one (even did a toy implementation which was quite fun). Wasn't aware it was by the CTO of Figma.
Post reply on HN