RobinPad's technical limitations in detail
In this post, I want to explain how RobinPad works, focusing on its technical limitations, from performance and device compatibility to the painting engine itself.
As you may know, RobinPad runs 100% locally in your browser. This means that everything, the tools you use, the strokes you draw, the files you export, and the settings you customize, is processed and saved directly on your device. Nothing is ever transferred to a server.
The Browser
While developing RobinPad, I researched the capabilities of various browsers, specifically their compatibility with input devices (styluses, tablets), gestures, and touchscreens.
Ultimately, Chromium-based browsers, such as Google Chrome, Helium, Opera, Edge, and Vivaldi, offered the best native support for essential features. They provide superior storage management, better privacy options, and more reliable stylus and multi-touch support. Consequently, I focused entirely on this engine, which is why RobinPad performs optimally in these browsers.
Storage and Performance Limitations
To start with, browsers don't allow an application to fully exploit a device's hardware, at least with the framework I chose, since I primarily have access to the CPU rather than the GPU.
They also restrict access to local storage for persistent data. Instead of full disk access, the browser allocates a limited amount of space per website based on the device's specifications. This allocation isn't fixed; it can range from a few gigabytes to 15 GB depending on the system.
Tablet and Stylus Compatibility
This has been one of the most challenging hurdles. To summarize: browsers don't identify the specific model of your tablet or stylus; they detect a generic device and apply a standard pressure engine. This means the app cannot natively leverage the specific drivers or custom pressure curves of individual devices.
Furthermore, because browsers weren't originally designed for digital painting, they often treat input as simple pointer events. This results in uncalibrated pressure curves and sudden 'jumps' at the start or end of a stroke. I've had to build a custom painting engine on top of the browser's native system to correct these inaccuracies, a process I am still refining.
Tips for Optimizing the Painting Engine
The logic behind digital painting programs is straightforward: whenever you drag the stylus, the brush tip repeats according to specific parameters (e.g., X times over a set distance), combined with pressure-based opacity and size curves. All of this must be rendered in milliseconds.
That 'magic' is actually pure logic.
RobinPad's optimization relies on tracking your movements, whether you are painting, pausing, or lifting the stylus. The heaviest processing load occurs when consecutive strokes must be rendered into a format the browser can display without lag while ensuring they persist on the canvas.
What happens next?
Here's a breakdown of what happens inside RobinPad: