Yesterday was a big day for the AutoCAD product. A multi-year engineering project – started in the AutoCAD team way back when I was part of it – culminated in its first deliverables getting into the hands (or, in this case, browsers) of customers.
The AutoCAD team has been working on a project codenamed “Fabric” for the last several years. It's has been a huge amount of work – something I’ll hopefully get into in a future blog post – but it’s finally bearing tangible fruit. In broad strokes the work was to take the core of AutoCAD and make it cross-platform. You might consider the Big Split – work that was done ostensibly to build AutoCAD for Mac but resulted in a Core Engine that became the mechanism through which developers could run custom code in the cloud via AutoCAD I/O (now part of Forge’s Design Automation API) – to be the first phase of this effort. At the very least Fabric stood on the shoulders of the Big Split.
The Big Split was a significant effort that resulted in code that could be cross-compiled on both Windows and OS X. It did so via various techniques, some of which were less than ideal with the benefit of hindsight (such as using #ifdef statements in various places to have conditional compilation on the two platforms). Fabric has done away with #ifdefs, forcing any platform-specific code into a PAL (Platform Abstraction Layer) per targeted platform. And Fabric is able to target more than just Windows and OS X. Some of the main targets were the established mobile platforms (more on that down the line), but one major effort was to target the web platform with the AutoCAD codebase.
Yes, you read that right… yesterday’s update to AutoCAD Web now runs the same core code as standard AutoCAD, but in a browser. A major part of AutoCAD’s C++ codebase gets run through Emscripten (at least that’s my understanding – I’ll correct any details I get wrong) to be transpiled into WebAssembly. This is huge. We’re finally able to have a single codebase that results in the same AutoCAD core technology working inside a web browser.
There are still significant gaps between the browser-based version of AutoCAD and its desktop-based sibling – 3D being a prime example – but these gaps will reduce, over time. It will also be much easier for the AutoCAD team to build new features that work across the range of AutoCAD’s platforms.
An interesting anecdote is around the recently discovered processor vulnerabilities – Meltdown and Spectre – and the impact these had on the project. Support for WebAssembly in modern browsers required the use of SharedArrayBuffers – a technology that’s vulnerable to Spectre. The AutoCAD team worked with the Chrome team to identify an alternative approach: after some nervous weeks of people having to use browser flags to force the availability of SharedArrayBuffers, AutoCAD Web once again works as well as it did before the vulnerability was discovered.
In an upcoming post I’ll talk more about the Fabric project, and what was involved: I know this blog’s readership will find the details interesting. The important thing for me in this whole effort is that it brings significant potential for a future where external apps and customizations could work on a wide range of platforms. This would be nirvana for developers who have spent many years investing in building desktop-centric knowledge and intellectual property. This isn’t necessarily something that’s coming in the near-term, but the promise is there, and it’s very exciting.
Update:
I’ve received some clarification from the AutoCAD team about the use of SharedArrayBuffers in WebAssembly. Apparently they’re not strictly required for WebAssembly to function (of course), but we originally used them to support certain synchronous retrieval operations the AutoCAD codebase has to perform. Many thanks to Kevin Cheung for providing this information.
