[Feature]: Add Support for Configurable Rendering Context (2D and WebGL)

[aticzz]

CheckList

• I agree to follow this project's Code of Conduct
• I have read and followed the Contributing Guide
• I have searched and referenced existing issues, feature requests and discussions
• I am filing a FEATURE request.

Description

Currently, Fabric.js utilizes the 2D rendering context (CanvasRenderingContext2D) for drawing operations on the main canvas. While it employs WebGL for image filtering through the WebglFilterBackend, there is no option to render the main canvas using a WebGL context. This limitation restricts performance enhancements that could be achieved through GPU acceleration.

Current State

Introduce a feature that allows developers to choose the rendering context for the main canvas, either '2d' or 'webgl'. This could be implemented as an option during the initialization of the Fabric.js canvas, for example:

const canvas = new fabric.Canvas('canvas-id', {
renderingContext: 'webgl' // or '2d'
});

Performance Improvement: Utilizing WebGL for rendering can leverage GPU acceleration, leading to smoother interactions and faster rendering, especially with complex scenes or a large number of objects.

Enhanced Capabilities: A WebGL context would enable advanced graphical effects and transformations that are challenging to achieve with the 2D context.

Additional Context

Implement checks to ensure the user's browser supports WebGL before initializing the canvas with a WebGL context.

[asturur]

That would be an entirely different library to be honest.

Webgl is born with 3d in mind, doesn't have rich TEXT functionalities, all the code to transform a custom font into polygons would be to be built as for code to draw beizer curvers and random paths, different fill methods.
2d drawing already uses gpu acceleration also, you can notice the difference when you turn off the hardware acceleration from your browser how much slower fabricJS becomes.

What makes you think it would be faster that much faster? The code that needs to elaborate all this geometry would still be JS.

Sure you could run the jumping bunny test much faster but when you go to generic drawing like text editing it wouldn't be so faster, geometry data would need to be rebuilt each key stroke and sent to the gpu every time. You could draw way more rectangles and polygons on screen at once, i m sure.

[aticzz]

Thank you for the response 😀
I understand that WebGL is fundamentally different from the 2D context and that Fabric.js is optimized for 2D rendering.

However, my main use case is rendering heavy 1080p video content from the Fabric.js canvas. I record the canvas using MediaRecorder, but when dealing with complex scenes, animations, and effects, performance becomes a major bottleneck. Since WebGL can significantly improve rendering performance for large-scale tasks, I was exploring ways to leverage GPU acceleration while keeping Fabric.js as the primary engine.

What I Have Tried So Far
Using webgl-2d.js (https://cdn.jsdelivr.net/npm/webgl-2d@0.0.2/webgl-2d.js)

• This library mimics the 2D canvas API while using a WebGL context under the hood.
• It provides similar methods to CanvasRenderingContext2D, so theoretically, Fabric.js could use it without modifying its architecture.
• I tried integrating it, but there were inconsistencies in rendering, and I faced issues in several parts of Fabric.js.

Modifying Fabric.js for WebGL Context

• I attempted to edit Fabric.js to work with a WebGL rendering context.
• Due to the complexity of the changes required, I decided to abandon this approach.

Since my architecture is entirely browser-based, I cannot offload rendering to Node.js or server-side processing. After recording the video with MediaRecorder, I use FFmpeg to convert WebM to MP4.

Do you have any advice on handling video processing more efficiently in the browser?
How can I use Fabric.js in the most optimal way for super-fast rendering of high-resolution (1080p) video?

Any guidance or suggestions would be greatly appreciated. Thanks for your time 😀