Around 2012, there was a startup called Famo.us who raised $30 million for a CSS-based 3D engine. Looks like they pivoted to some kind of brand CMS eventually:
Secret sauce was basically every element absolute positioned, with an event loop that was diffing a CSS transform tree each tick. Worked pretty well, but was basically a workaround for browser performance issues that ended up being fixed anyways. (Was hired by them to do their React component library long ago)
It’s an awfully big stretch to hype that up as some kind of direct GPU access, as in this quote from the TechCrunch article about the pivot:
“By bypassing the CSS and HTML renderers to talk directly to the graphics processing unit, Famo.us could supposedly make 3D physics and other visual wizardry common with native games run smoothly for apps in a mobile or web browser.”
Journalists always simplify things to the point they become meaningless.
But avoiding DOM layout and its performance issues was relatively innovative at the time. It wasn't unheard of, but no one had really turned it into a framework like they did.
You can't blame journalists when the CEO of the company was actively spouting this "interfaces directly with the GPU" bullshit to describe multiplying some matrices in JS.
This article is hilarious. Or depressing. Maybe both.
"During the company’s debut on stage at TechCrunch Disrupt SF 2012 Startup Battlefield competition, rather than giving a traditional pitch, Famo.us CEO Steve Newcomb spent his whole six minutes asking people to imagine what could be done if apps were 3D instead of 2D and demoing a floating periodic table. [...] just days earlier, the team made its first pivot away from what it called BenchRank, a ranking system for people, into an HTML5 development platform."
"When TechCrunch reporter Anthony Ha visited [their offices], [Famo.us's CEO] pointed to some desks that seemed adequate, but insisted they would be replaced soon because they weren’t the right kind of wood."
It is now 2019 and the front page of famous.co has a big video and a pre-order button. One begins to wonder if this is an actual company, or an excuse to get a lot of VC so its CEO and a few lucky employees can afford to have nice places to live in SF.
The upper link can absolutely grind Android Chrome to a halt.
Force closing the app doesn't fix it either, as chrome reopens the last tab you had open, so the only way out is to completely wipe the browser data which is a little annoying.
I tried it on Chrome, Lightning, Privacy Browser, Firefox, Fennec en Firefox Klar ('always in privacy mode'), it works fine on all of these. Tested on Android 8.1 on a Xiaomi Redmi Note 5.
Strangely enough the image looks far better - as in more or less like it should - in Firefox (67.0a1) while she looks like Freddy Krueger's offspring (wrong colours, translucent areas which should be opaque or the other way around, etc) in Chromium (72.0 build 3626), both on Debian (Sid). I say this is strange as the author explicitly mentions she only expects it to look as it should on Chrome.
Win10, FF 66, I get what seems close enough to 60fps, but some graphics glitches too, mostly the texture around the barrels which doesn't go all the way "around".
Edge has always been extremely fast and competitive with other browser engines. It really shocked me when they deprecated it because in the last year of developing an app that only targets chrome and edge, I've never once had a bug that was edge-only. It seems that MS was never able to get out of the shadow of IE.
The problem with Edge is that they wrapped the engine, which was great, inside a UWP app, which are known to be stupidly ugly and stupidly sluggish. That's what killed it. Had they chosen Win32, it wouldn't have died. But I guess we will never know.
Shouldn't Firefox be prioritizing fixing those things instead of BS moonshot projects they do (not talking about Rust, but various non-browser pivots).
They might be "different teams" doing each, but they all have finite resources to pay them.
WebRender currently (as of the last 2 weeks) renders this correctly, but slowly. Now that correctness is in, they can start looking at speed. Associated bug is https://bugzilla.mozilla.org/show_bug.cgi?id=1525420 , but it’s not a blocker for launching WebRender in the first place.
And no, this sort of thing isn’t particularly high priority. If lots of websites used these technologies to this extent then it’d be higher up the priority list I’m sure.
Sorry, yes, it’s the Rust GPU rendering (not layout) engine that’s being introduced into release Firefox at the moment. Lin Clark wrote a great article on it 18 months ago: https://hacks.mozilla.org/2017/10/the-whole-web-at-maximum-f... . It should eventually be considerably faster than it is at the moment, but obviously there’s been a bunch of performance work in the previous Firefox rendering engine so currently it’s a clean codebase that’s moderately faster.
That's nice -- does that replace all rendering parts with the new Rust (servo?) equivalents?
Or are some parts still in the C++ codebase? (rendering related, not the UI code/JS engine, etc).
The diagram on the link seems to imply this is the last part! Does that mean there's some drawing library (akin to Skia) written in Rust used by WebRender too?
I’m just an interested observer so handful of salt, but I believe WebRender replaces Moz2D and the old drawing libraries (which included Skia). Honestly, at this point I’m going to defer to pcwalton or whoever’s on HN that’s closer to the project than me.
I remember seeing his old one in 2012 and spending an 8 hour plane ride with a bottle of vodka and a laptop trying to recreate the windows maze screensaver the same way. (Needless to say, the vodka was the only winner)
Looks good, I don't know if lighting is pre baked or what but I was surprised. EDIT: Site does mention lightmaps.
Running on Chrome on Android on a Pixel XL I did encounter the following:
* Freelook camera allowed for too fast of movement, the engine struggled to keep up. Panning back to polys that were in view less than a second before reveals that they've been unloaded the instant I looked away. This allowed me to see through walls to polys that should have been fully occluded and would have been much safer to cull. What was rendered would only seem to update if I moved either stick, and so after I started to have issues I never managed to have a correctly rendered frame again. Loading missing polys would mean bringing more unloaded polys into view. Seems like one of those bugs where I would believe it took 5 seconds or 50 hours of work to resolve.
* I did start to notice the vertical seams on the barrels on my second time through, this time with the automatic camera mode. Once I noticed them, I wasn't able to stop, it was very distracting.
EDIT: I went back in to confirm, the mobile control version does not show vertical barrel seams, while the auto camera version does. Different builds for each perhaps?
I feel high quality 3D is one of the final things that we need to master in the browser. Once this is done, I can imagine PWAs get more widespread adoption for gaming and AR etc.
Since the browsers black list GPUs and platforms where they have issues, as author you don't have any guarantee how the users will get to see your site.
Additional not all GL ES features are exposed to WebGL.
Depends on your definition of fine. In certain cases it would crash browsers on load, in other cases it would deliver a solid 60fps. I think 3d on the web does need a bit more polish so that it's a good experience universally.
The Unity engine has been outputting WebGL builds for years, and having played a bunch of them (and deployed a few myself), I've never once seen a problem that didn't exist in other builds of the same game
https://techcrunch.com/2015/11/06/nopen-source/
The company claimed to have a secret sauce for accelerating HTML5 graphics, which turned out to be the matrix3d() function for CSS transforms.