Web Vs Native Rendering

Let’s say you’re planning to start building your next big application, and for this you need to tackle the age-old problem of drawing things to the screen.

You bust open your favorite search engine and… what’s that? Rendering?

Rendering is the process of creating a 2D image on any screen given a combination of a virtual camera, light sources, 3D objects & 2D textures, depending on whether you’re keeping things strictly flat with 2D, or adding some new perspective (quite literally) with 3D.

Even a primitive screen as one in the calculator is rendering numbers and symbols using LEDs.

Now creating images from a 3D scene is tedious, even for the computer. Which is why, first generation (earlier) solutions to this problem was rendering everything in advance and just serving you the finished product built from silicon blood and sweat.

This was aptly named Offline rendering.

Offline rendering does not require interactivity. This means that the same set of generated images is meant to be viewed by a large audience. Due to the lack of interactivity, offline rendering does not have strict time limits to render or generate images. Movies often use offline rendering to achieve hyper realistic images, which often take hours, if not days to render, often requiring large render farms to achieve the desired image quality. For example, each frame / image of Disney’s “Frozen”, took over 50 hours to generate!

Offline rendering can be done on the CPU itself, or can be done with multiple GPUs in a distributed fashion.

But, can we do better?

Enter Real-time rendering!

Real time rendering is an extension to the rendering concept - where 2D images are generated quickly enough so that viewers perceive a continuous visual experience, rather than seeing individual images one at a time. Now with a flipbook so advanced that images are poured in front of your eyes at 30-60 FPS (or even higher if you have a fancy monitor!), you can barely tell them from a live experience. This type of rendering is primarily used for interactive applications like Video games such as GTA V and Stardew valley, or simulation applications like Embergen.

In real time rendering, each frame must be rendered in a few milliseconds to minimize input lag, ensure there is no delay between user generated input and the generated output being displayed to users.

Now, all this is clearly too much toil for the humble CPU that is already carrying your software logic on its back. So, we follow the single greatest advice that any computer technician could give - get better hardware.

Or, in this case, a very specific type of hardware - Graphics Processing Units (GPUs). A GPU is at the core of a Consumer Graphics card like RTX 3090 etc.

GPUs are essential for real time rendering. GPUs are specialized hardware designed to handle parallel processing tasks efficiently. While GPUs can also perform non-graphics-related computations (often called ‘compute workloads’), rendering graphics is one of their primary functions.

In order to use GPUs for rendering graphics or performing non graphics compute workloads, a Graphics Application Programming Interface(API) is used. Graphics APIs create a bridge of communication between the GPU driver and the application program, abstracting the complexities of different hardware vendors (AMD, Nvidia, etc). APIs allow the declaration of tasks that need to run on the Graphics Card without tending to every single implementation detail, not very different from using a programming language with compilers that generate machine code. This allows developers to work with a unified interface, which largely minimizes the need to change the program based on the hardware specific details.

Alright, let's dive into Native rendering.
Native rendering, as we speak of it here, is the traditional method of drawing on a screen using - Native GPU / graphics API’s like OpenGL, Vulkan, DirectX12 etc. Remember the DirectX error it used to throw in your PC in the 2000s when you wanted to play your newly bought video game? Yes, it's the same DirectX.
Rendering on native systems essentially means rendering applications built specifically for devices running operating systems such as macOS, Windows, Linux, Android and iOS. This could mean your PC, phone, tablet or any other native device. 

Graphics programmers before the turn of the century had to remain captive to a preset configuration method, known as the Fixed Function Pipelines (FFPs) -

• Developers used predefined functions for lighting, transformations, and textures without much control.

• There was no support for shaders (which is at the core of modern rendering) until the early 2000s.

Modern graphics APIs have largely liberated developers from these restrictions, providing much finer control over GPU resources, memory, synchronization and pipeline state. With enough knowledge of the underlying hardware, developers can architect their renderers to extract as much performance as possible from the GPU. 

This only goes to show why Native rendering is so desirable.

What are the APIs available for Native rendering?

Native Graphics APIs : DirectX(12, 11), Vulkan, Metal, OpenGL.

In recent years, GPU and Graphics APIs have become much more ‘low level’, providing the developer with a lot of control of the GPU. Synchronization primitives, advanced memory control, etc can be leveraged by developers who know exactly how the program works, so that they can architect the renderer as per their requirements. 

OpenGL is an outlier among the above and using it in this day and age might not be the best idea. Why? In APIs such as OpenGL, the graphics driver makes several assumptions about the program, which does make the development process much easier, but does not provide developers with fine grained control.

Meanwhile, APIs like Metal and DirectX are locked to their vendor ecosystems (Apple and Microsoft respectively) which makes them unfavorable for cross platform purposes, leaving us with Vulkan, an open source API with cross platform support by the creators of OpenGL themselves.

This level of control is particularly valuable for performance-critical applications. AAA games such as Halo Infinite, resource-intensive applications such as Photoshop, and simulation software such as Embergen can all benefit from carefully optimized GPU usage.

Most modern AAA games and other GPU-intensive applications therefore use native rendering APIs. Cross-platform APIs can reduce development time and increase portability, but when performance and hardware control are the primary concerns, native APIs remain the standard choice.

Now to save all the web developers among you from screaming that the browser already solved the problem of cross-platform compatibility for decades, we come to the meat of our discussion with a method of rendering that threatens to render (pun intended) the native platform obsolete.

Welcome to Web Rendering!

With the advent of the web, developers have become more and more daring in pushing the limits of what could be achieved within the browser itself, and as a direct product of this effort we gave birth to rendering in web browsers, termed here as Web rendering.

Web rendering lends a hand in utilizing the GPU from the comfort zone of Javascript, the web's own scripting language. Being fully integrated with other web standards, web-rendered elements can be mixed with other HTML elements and composited with other parts of the page or page background. It started with the introduction of WebGL, a Web Graphics API based on OpenGL.

Web rendering is cross platform to a large extent, and unlike Native rendering, ‘sharing’ your project with others becomes as easy as sharing a URL. The growth of the open web was monumental in pushing these Web rendering APIs by enabling cross-platform access, community-driven tools, and standardization across browsers for easy, universal 3D graphics. 

What are the APIs available for Web rendering? 

Web Graphics APIs: WebGPU, WebGL.

WebGL is based on OpenGL ES, exposing a JavaScript API for hardware-accelerated graphics in the browser. A simple to use API, that can be used to quickly get graphics up and running on the screen. However, recent advancements in WebGPU have made it a very compelling option for future projects.

WebGPU allows web developers to take advantage of the system’s GPU resources much more than WebGL ever could. The API is inspired and is similar to other modern GPU APIs, since it heavily reduces the CPU overhead, features first class support for Compute / GPGPU computations, etc. Compared to WebGL, more work can be moved from the CPU and JavaScript side onto the GPU, particularly through compute shaders. 

WebGPU is a combined effort of the W3C GPU for the Web community, with contributions from companies including Apple, Intel, Google, Microsoft and others. While WebGPU is now supported by major browsers, it is still not universally available across every browser and platform. For applications targeting a broad audience, WebGL may therefore remain the safer choice, while WebGPU is increasingly compelling for projects where modern GPU features and compute capabilities are important. 

As Web rendering is browser based, applications that use these tools will run on any platform / OS, as long as the browser used supports them. Three.js, which is a Javascript library that is an abstraction built on top of WebGL has made it easier for thousands of developers to run 3D on the Web.

Considering that Javascript is the most used programming language in the whole world, Web rendering is much more accessible to beginners compared to Native rendering, as the initial learning curve is much easier to climb.
Web rendering has traditionally been used for things such as small games, interactive visualizations, websites with 3D effects and browser-based creative tools. WebGPU expands the possibilities considerably, making increasingly demanding applications feasible directly in the browser.

Our own project, Quantales, is a good example of just how far web rendering can be pushed. We built an ambitious, fully 3D animated story for children, complete with interactive elements, cinematic camera movements, custom shaders and carefully timed animations, all running directly in the browser. We managed this by extracting as much as we could from WebGL and being deliberate about optimization, from loading scenes only when needed to keeping rendering costs under control. We chose the web precisely because we wanted the experience to be accessible through a simple link, without requiring parents to install a separate application or worry about platform compatibility. It wasn't without its limitations, but it showed us that the browser is capable of considerably more than the usual lightweight 3D demos.

Tools such as Shadertoy demonstrate another advantage of the web platform. Users can write, experiment with and share GPU shader programs directly through a browser without requiring a traditional development environment or distributing an application binary.

Now with an updated view of what rendering methods are available for us on native and web platforms it might be a good call to wrap our heads around when we would want to use what and whether to optionally take pride in choosing one over the other.

Comparing Native vs Web rendering

The fundamental trade-off is fairly simple.

Native APIs provide greater control over the hardware and expose a broader range of GPU-specific functionality. Web APIs sacrifice some of that control in exchange for portability, accessibility and straightforward distribution.

For example, WebGPU does not expose the entire feature set available through modern native APIs. Features such as hardware ray tracing, GPU work graphs, bindless-style resource access and certain advanced GPU operations may be unavailable or more restricted in the portable WebGPU environment.

If an application depends heavily on such features, native rendering is usually the better choice.

Native APIs can also be particularly valuable for AR / XR applications, where low latency, predictable frame timing, synchronization and careful memory management are critical.

Mobile applications can similarly benefit from native APIs when developers need tight control over device-specific hardware and power consumption.

On the other hand, if the application is relatively lightweight or primarily 2D, a web-based renderer can often provide the required performance while making deployment considerably easier.

When is Web rendering more suitable?

1. Distribution

You want people to use your application without installing anything. Deploy it, send them a URL, and you're done.

2. Cross-platform applications

If the application needs to work across multiple operating systems and devices, the browser provides a common runtime, assuming the required APIs are supported.

3. Prototyping

Modern native graphics APIs can involve a substantial amount of setup before anything appears on screen. WebGL and higher-level libraries can make it considerably faster to turn an idea into a working graphical prototype.

4. Integration with the Web

If your application already depends on technologies such as HTTP, WebSockets, browser storage, authentication or cloud services, working within the web platform can simplify the architecture.

When is Native rendering more suitable?

1. Maximum performance

AAA games, demanding simulations and other performance-critical applications can benefit from the additional hardware control available through native APIs.

2. Low-level optimization

Native APIs allow developers to target specific hardware and exploit device-specific capabilities that may not be exposed through a portable web API.

3. Low latency

Applications such as AR/XR can require precise control over GPU scheduling, synchronization and memory usage that is difficult to achieve through a browser abstraction.

4. Offline and standalone applications

If an application needs to operate independently of a browser or network connection, a native application is usually the more appropriate choice.

5. Controlled environments

If you know exactly what hardware and operating system your application will run on, targeting that environment directly can allow optimizations that would not be possible through a portable web abstraction.

Asset management in Web vs Native rendering applications

There is another practical difference between Web and Native applications that is easy to overlook: how do we actually get all those assets onto the user's machine? 

In native applications, the assets (3d models, textures, etc) are usually shipped with the program in compressed form. When the program wants to ‘load’ these assets into the program, appropriate decompression algorithms and streaming techniques are used. Assets are a large reason why modern games can be several 100 gigabytes large. This makes the time between starting a download and actually using the application very long and inconvenient. However, it is a one time process, which cannot be said for web applications.

In Web rendering, a few options are available. The models can be stored on a server, and when the website is accessed, small assets can be cached on local storage (so that small assets  can be cached in between sessions). Optionally, assets may be downloaded onto the client side browser memory, if assets are fairly large.
The problem here is that large assets will have to be redownload each time the user visits the webpage : This is an issue if developers (such as the ones working on AAA games with assets that are several gigabytes) want to port their application to the web.

We could easily circumvent the problem of initial load times by only loading lightweight assets and rendering the scene at a lower LOD (level of detail) initially, while progressively streaming higher-quality assets[1] as needed. This simple trick allows us to prevent overwhelming the poor browser while also providing a smooth experience to the user.

Developers have come up with increasingly innovative techniques to further optimize web rendering. Wonder Interactive Inc., even goes so far as to compile their own version of Unreal Engine 5 with built-in support for a WebAssembly target, a format that could be run directly in the browser.

Content Delivery Networks (CDNs) can help distribute assets across multiple servers, which can improve download speed and reduce latency issues.

Also, security is a major concern. Developers have to ensure that cross origin requests and other potentially harmful security issues are not present. This is a concern for native applications as well, but since assets will have to be downloaded multiple times if the user accesses the webpage multiple times, it becomes a key factor to consider in web applications.

How Do We Actually Build This Thing? 

Performance is only one part of choosing a rendering platform. We also need to consider the development experience: what tools are available, how easy it is to debug problems, and how much effort it takes to build and maintain the application.

Development Environment for Web vs Native rendering applications

Native applications often have excellent tooling and a wide variety of IDE options to choose from, such as Visual studio, Xcode, etc. Furthermore, when using GPU APIs like Metal, Xcode has several built in debugging tools that make the development and debugging experience very convenient.

Web tools may not provide as much insight into the application as native tools, but the situation is rapidly improving. Tools like Chrome Dev tools offer integrated debugging and profiling capabilities for WebGL and WebGPU applications.

Quality of Life features like hot reloading are much more ‘polished’ for web applications, compared to native tools, where this feature is present in tools like Visual studio, but do face problems and inconsistencies regularly.

User experience in web vs Native rendering applications

Ever taken a day off to play the latest AAA game such as Call of Duty : Warzone, just to find out that there is a large 100+ gigabyte update waiting for you? This situation can easily be avoided on web applications, where updates can be deployed directly to the server, and users always access the latest version of the application without any manual updates.

Conclusion:

Between Web and Native rendering, it's all about choosing the right tool for the job. If you're after raw power, pushing your GPU to its limits with AAA games or simulations, Native rendering is the way to go. But if you want to share your work with just a link and cross-platform ease sounds like a dream, Web rendering is your best bet. 

At the end of the day, it’s all about performance vs. convenience. The choice belongs to you, or to be frank, your intended user base.