Port and integrate the Artist library with elements

[djowel]

Integrate the Artist library with elements

• Backport Cairo to the Artist library
  • Colors, Styles, and Shadows
    • fillStyle
    • strokeStyle
    • shadowColor (no shadows in cairo)
    • shadowBlur (no shadows in cairo)
    • shadowOffsetX (no shadows in cairo)
    • shadowOffsetY (no shadows in cairo)
    • createLinearGradient
    • createPattern
    • CreateRadialGradient
    • addColorStop
  • Line Styles
    • lineCap
    • lineJoin
    • lineWidth
    • miterLimit
  • Rectangles
    • rect
    • fillRect
    • strokeRect
    • clearRect
  • Paths
    • fill
    • stroke
    • beginPath
    • moveTo
    • closePath
    • lineTo
    • clip
    • quadraticCurveTo
    • bezierCurveTo
    • arc
    • arcTo
    • isPointInPath
  • Transformations
    • scale
    • rotate
    • translate
    • transform
    • setTransform
  • Text
    • font
    • textAlign
    • textBaseline
    • fillText
    • strokeText
    • measureText
  • Pixel Manipulation
    • drawImage
    • width
    • height
    • data
    • createImageData
    • getImageData
    • putImageData
  • Compositing
    • globalAlpha
    • globalCompositeOperation
  • Other
    • save
    • restore
    • createEvent
    • getContext
    • toDataURL
  • Artist Extensions
    • pre_scale
    • fill_preserve
    • stroke_preserve
    • add_round_rect
    • add_circle
  • Artist Examples
    • composite_ops
    • paths
    • rain
    • shadow
    • shapes
    • space
    • tauri
    • typography
• Port and integrate the Artist library

[djowel]

The checklist above is the w3c "canvas" feature set. Not all of these are supported by Artist, and there are some, such as advanced typography, that w3c does not support.

[djowel]

So this is the current state of what is in elements that artist requires, plus a few more low-hanging fruits. Some will not be implemented if they are not directly available in cairo (e.g. shadows; there are hacks but very slow, it's not worth it).

The tricky part that will take time is not really part of w3c canvas: text layout and typography. The Skia port uses harfbuzz text shaping library; very powerful, The Quartz-2D port uses its native text layout engine, also very powerful. I suppose the Cairo port can also use harfbuzz.

But I am increasingly losing interest in continuing this Cairo backport, and instead I am leaning towards devoting my time on directly going to Artist with Skia/Quartz-2d. There's still so much to do, and time spent on backporting can instead be allocated to more important matters. Cairo is a dead-end to me anyway. Cairo development is stagnant.

Your thoughts? Is the Cairo Artist backport still worth pursuing?

[djowel]

Here's a screenshot of Artist typography:

Paragraph layout, in particular, is not part of w3c canvas. Shadows and glows are not available in Cairo. Shadows and glows are really cool! Example:

[djowel]

Without shadows and glows, Cairo looks pale in comparison:

[Xeverous]

What's the reason for going with W3C canvas API?

Do you want to have 1 common interface for multiple (including possibly custom) implementations or "the only implementation"?

[djowel]

What's the reason for going with W3C canvas API?

Because it makes sense? I'll throw back a question to your question to my question: Why not?

(I don't think I understand your second question, but both of these seem irrelevant to my original question)

[Xeverous]

Why not?

Why not implement a full HTML-based UI then? There are a couple of ideas like this: HTML for layout, CSS for styling, C++ instead of JavaScript. I have seen at least 1 commercial library doing this. The advertising is basically "capable of rendering any webpage layout but with much more performant logic".

[Xeverous]

I get that you searched for any standard, or to have a starting point - but IMO HTML5 canvas might be too far different, just like web tech is very far from C++. I would rather look at multiple graphic libraries and try to find a common API between them.

[djowel]

@Xeverous these topics are irrelevant at this point. Please do not hijack the topic and move it in another direction. If you want to implement a full HTML-based UI, be my guest. If you want to build your own API, be my guest. But that is not the topic here. Nor is the API being questioned here. These are design decisions done very early on.

[djowel]

To be honest, It's tempting to answer your questions, but I do not want to digress.

[Xeverous]

I would keep cairo - even if it's subpar to skia one can always have an extra implementation, maybe for dependency reasons or whatever similar. Maybe just to try out the library in case someone has cairo (as its pretty old and could be easily apt-get'd) and does not want to build other implementation.

[djowel]

Some comments in the Discordchat room:

RedTideToday at 3:41 PM
I was about replying against keeping Cairo but I'm not sure if its API is exposed in elements or are all hidden behind the current elements API. If hidden I don't see a reason to keep it if it will be replaced with a better one. I saw UI ports dropped in other UI (wx at least), I don't see why not dropping a backend for the underlying 2d api
djowelToday at 4:46 PM

@redtide Cairo is abstracted away by the w3c canvas API, in most part. Remember, Elements did not start with Cairo. It actually started with NanoVG. There's one part that directly uses Cairo: text layout. But that will have to be replaced anyway with the switch to Artist.

jpcimaToday at 4:56 PM
after having artist and once cairo is removed, this will mandate use of opengl I guess?
@djowel I wonder, how are you hosting in your vst plugin ? do you base it on direct OS API like Win32?

djowelToday at 4:58 PM
yes. opengl, with skia. Will that present problems? Mac-OS with Quartz-2D OTOH is just plain Cocoa.
for plugins, have this thing called QPlug, which is currently based on iPlug2 and Elements.
It's still pretty much private, no docs, etc, but: well... https://github.com/cycfi/qplug

jpcimaToday at 5:01 PM
for opengl, this is fine mostly. usually it's limited to very few user complaints with old machines, it's why a software fallback is nice, but not obligatory

djowelToday at 5:03 PM
well, that's one consideration for cairo
but how will it work in that case, maintain two binaries? one targets skia and another targets cairo?

jpcimaToday at 5:06 PM
this may work as a solution; it depends the requirement of the plugin, if UI doesn not move a lot, software-only is sufficient

djowelToday at 5:08 PM
I suppose we can keep and maintain the cairo port for elements, as it is right now, and backport new code to it regularly. might be a maintenance nightmare, but IDK.

jpcimaToday at 5:08 PM
but just to insist, this is not a requirement, I notice some current commercial plugins are requiring openGL3 or more

djowelToday at 5:09 PM
Most of the 2d graphics code in elements are stable anyway.

jpcimaToday at 5:09 PM
these plugins can still work on old machines with workaround of software GL, although really slow

djowelToday at 5:10 PM
The real issue is when people start using the canvas-2d api, but that too requires very minimal adjustments from current element::canvas to artist. The Artist API is a superset.
And the real pain will be if some folks actually use cairo directly
OK, well, how about we put it to a vote? Also, can we have these comments in the issue so I can refer back to it in the future?
This is a major decision I do not want to take lightly.

jpcimaToday at 5:19 PM
to be clear, I'm not pushing for cairo to be kept absolutely, especially if this complicates the software

RedTideToday at 5:19 PM
maybe a pro/cons list would be helpful? Like, are barebone/RPi like machines taking advantage of cpu 2d?

djowelToday at 5:20 PM
good idea
oh wow, i don't know about RPi, but that is a very GOOD point!

alexmitchellmusToday at 5:21 PM
My two cents: If it's for GUI (not image processing) then I don't see any issue with OpenGL on iGPU. RPi should have some acceleration no?

djowelToday at 5:22 PM
yes it does. but i have no idea how well skia performs with RPi

alexmitchellmusToday at 5:23 PM
Well- ARM RPi is basically ARM mobile no?

djowelToday at 5:24 PM
right!

alexmitchellmusToday at 5:25 PM
If anything, it may improve the performance, and leave the CPU to do, er, DSP?
djowelToday at 5:25 PM

https://www.reddit.com/r/raspberry_pi/comments/cfdxpk/skias_nanobench_results_on_rpi4/
reddit
r/raspberry_pi - Skia's nanobench results on RPi4

RedTideToday at 5:25 PM
maybe depends on the driver, I recall mpg rendering had some commercial thing

djowelToday at 5:26 PM
And an equally valid question: how does cairo perform with RPi to begin with?

alexmitchellmus
If anything, it may improve the performance, and leave the CPU to do, er, DSP?
@AlexMitchellMus True. At least it should. But there are unknown factors that it's hard to predict without actually trying it.

RedTideToday at 5:29 PM
it seems they are more or less all capable of opengl
also how old a machine should be to not support it?

RedTideToday at 5:42 PM
I'm reading that Skia has also software rendering backend

djowelToday at 5:43 PM
Oh, yes it does! WHy could I forget that!
actually, cairo has a gpu backend too, albeit experimental

RedTideToday at 5:45 PM
so it means there will be different build anyway (cpu no gl and gpu with gl)?

djowelToday at 5:45 PM
@redtide will you list down the pros and cons in #219? I'll add some more if you start one list.
BRB. I need some coffee :slight_smile:

RedTideToday at 5:46 PM
the only pro in cairo I see is the cpu for old machines 😛

djowelToday at 5:46 PM
LOL :slight_smile:

RedTideToday at 5:46 PM
later

djowelToday at 5:46 PM
that's a good start anyway. haha!

RedTideToday at 5:47 PM
I mean, IIUC if skia can work also on old machines with a cpu backend there is no reason to maintain cairo as well

djowelToday at 5:48 PM
right! absolutely.

[djowel]

Closing this now. So the consensus is to no longer support Cairo.