wondering what the recommended approach would be f...

# compose

[Trejkaz]

wondering what the recommended approach would be for implementing something like a paint application. I've had a bit of a look to see what's out there, and it looks like everyone is just using a Canvas and then looping lines or paths to draw - does this approach scale to complex drawings, or should I expect things to break if the number of lines it has to draw gets large? I was originally thinking of drawing onto bitmaps, but keeping bitmaps in state isn't the easiest thing to do either.

[rharter]

I spent around 5 years as the lead developer of Pigment for Android (until we gave up trying to figure out how to make money with a coloring app on Android 😓).

Pigment was a native Android app that used OpenGL for rendering so that we could use GL shaders for high quality, realistic rendering. Everything it had to render was stored in the app space, and we managed textures, lines, points, etc all there and transferred things to the GPU to render. This worked out quite well and scaled to handle hours and days long coloring projects.

While that's not the Canvas approach you mentioned (which I also have lots of experience with), I share this because it's very similar, and I believe it can scale quite far. You can easily start with a live canvas approach which is simple, then add optimizations over time, like tiling, Picture based snapshots for super fast undo/redo support, etc. this approach can scale, and if Android had access to Skia shaders at the time (and I had known what I know now about this stuff) I would have even considered making Pigment with Canvas APIs!

If you haven't seen it, I'd recommend checking out Dan Sandler's Markers project on GitHub. Sure, it's very old. But it also demonstrates a lot of really good techniques that are easy to translate to a larger, more modern system.

[Trejkaz]

I did have the wild idea of making an image editor which worked almost entirely using shaders a while back, just never settled on a sensible framework to write the thing in

[rharter]

You don't need a framework for this stuff. Filament is a really good example of a cross platform library that uses OpenGL (or Metal) to render things. It backs a bunch of the AR Google Maps experiences, and many others.

[Trejkaz]

well, text rendering, for one thing, is scary

[Trejkaz]

I've been having a really bad time with input devices in some other projects as well

[Trejkaz]

and then by the time you think you have keyboard input working properly, some user from Japan or somewhere comes in saying their IME doesn't work right

[rharter]

That's fair. Text rendering is always a pain. The other stuff is all kind of platform dependent. You could use something like Unity, but don't need to, as you can have the renderer and it's stuff be cross platform and use native code on whatever platforms you support for the app shell. That's effectively what we did, though only the shaders were shared. Going back I would have shared at a slightly higher level than that (using something that exports a C ABI, like C++, KMP, or something similar).