Fully abstract rendering layer

[eakoli]

It looks like elements::canvas is almost entirely attracted out (except for the cairo_t& constructor). And there are partial abstractions for font and glyph (they have a few aliased cairo types / cairo code inlined in header).

Was the intention to fully abstract out the rendering layer?

Doing so would allow macOS/iOS use using just CoreGraphics w/o needing to bring in cairo on those platforms.

[djowel]

Check out the main branch where I do just that using the artist library (https://github.com/cycfi/artist) that uses CoreGraphics or Skia in MacOS, and Skia in WIndows and Linux. The main branch is the future of Elements and is maintained alongside cairo_2023 branch, only for Cairo, which will be phased out eventually.

[eakoli]

Is the intention to remove cairo support? As it looks like artist is currently only Skia or Quartz

[eakoli]

I looked over the main branch, unfortunately right now I have to stick on master/cairo_2023 as artist (Skia) wont work on the level of systems we need to support. And that branch adds too much c++17 only code (currently locked to c++14).

Im currently working on a PR to allow both the host and the canvas to be implemented externally (thus elements itself has no hard dependencies on either for compilation)

[djowel]

Is the intention to remove cairo support? As it looks like artist is currently only Skia or Quartz

Yes. Cairo is a dead end.

Im currently working on a PR to allow both the host and the canvas to be implemented externally (thus elements itself has no hard dependencies on either for compilation)

OK, but please keep in mind that this has to be 100% compatible with main. The current workflow for any major work :

1. Make a feature branch from main
2. Work on the feature branch
3. Incrementally rebase, merge feature branch from main until stable
4. Merge to main
5. Merge cairo_2023 from main

And that branch adds too much c++17 only code (currently locked to c++14).

Take note, though, that C++17 has always been the baseline requirement, as mentioned in the setup guide and the near-future target is C++20.

[eakoli]

Did you run into issues with cairo? or was it just simpler to use Skia?

For me Skia brings in too many dependencies.

What was enticing about elements (Based on the master branch) was that it had very few dependencies and had a very simple "host" integration model. We have to integrate into an existing windowing ui library, and the ability to easily and transparently use elements as a subview of the existing toolkit makes it idea as a migration path to the declarative model.

[djowel]

Cairo (the library) is virtually dead. The last entry in the roadmap was in 2017: https://www.cairographics.org/roadmap/ and still unimplemented to this day. As for keeping it in Elements is one thing I still find difficult to decide, and I am going back and forth, whether to keep it of move along.

Artist too has a simple integration model, and probably could have an even simpler (slim) API (**). Yes, I care about dependencies. Yes, you are right about Skia baggage. That is why it also supports Quartz2D for the MacOS (my main dev platform). Artist, like Elements, is meant to easily adapt to a target.

(** this slim API can probably support Cairo, like I used to in Elements. There's actually an unfinished cairo port in ELements).

Interestingly, I am working on a project right now that's most likely going to stay with Cairo. Tough decision to make, and yours is a compelling argument.

[djowel]

For me Skia brings in too many dependencies.

Man! You make a very compelling case! Ideally, I should probably have to really complete the backport of Cairo to Artist.

[djowel]

And that branch adds too much c++17 only code (currently locked to c++14).

Take note, though, that C++17 has always been the baseline requirement, as mentioned in the setup guide and the near-future target is C++20.

I would probably suggest that a better and likely easier approach is to have a C++14 mode in elements and artist. I don't think there's too much C++17 code yet (e.g. having a replacement for std::filesystem for compability). Being locked to C++14 is a common situation. I did attempt to move to C++20, but reverted due to the build problems with Skia. Now I might be reconsidering my plans out of pragmatism. This is also the reason why I am keeping and maintaining the cairo branch.

[eakoli]

yea...I noticed that its officially stated as c++17, but master (which is the current "primary branch" of the repo), doesn't use THAT much, and I didn't look into the main branches use, I stopped after I noticed the use of std::variant.

_v variants of traits (easily fixed by removing _v and adding ::value)
std::size ( one place, simple to re-write)
for( declaration variable ; test ) construct that is c++17, but in c++14 mode just issues a warning that you should use c++17 mode
nested namespace declarations (e.g. namespace cycfi::elements vs namespace cycfi { namespace elements { ), again just a warning.
structured bindings, again just a warning.

[djowel]

FWIW, there are C++11/14 versions of variant. E.g. https://github.com/mapbox/variant

[djowel]

Artist, like Elements, is meant to easily adapt to a target.

Except for text layout which is a VERY tough nut to crack! And is one of the violations in "classic-cairo" based Elements with direct cairo calls instead of going through the API. Alas, text editing (at the very least input boxes) is a crucial part of a GUI.

[djowel]

Alright, I did a review of the artist text layout code. The required "host" integration can be simplified down to a single canvas call (drawing glyphs at positions). All the rest can be made generic in c++.

[djowel]

Update: I was able to build Skia with minimal dependencies using this gn call:

bin/gn gen out/cmake --ide=json --json-ide-script=../../gn/gn_to_cmake.py --args='
    is_debug=false
    skia_use_angle = false
    skia_use_icu = false
    skia_use_lua = false
    skia_use_piex = false
    skia_enable_tools = true
    skia_enable_pdf = false
    skia_use_gl = true
    skia_enable_skottie = false
    extra_cflags_cc = [ "-frtti" ]
    '

Now Skia's dependencies are limited to libjpeg, libpng, libwebp and zlib, all with very small footprints:

These additional libraries are all integral to any modern GUI anyway.

[djowel]

@eakoli As announced in discord:

main will now become master. develop will sync and track master and will be the transient staging ground. cairo_2023 will persist as long as possible, but might be phased out, unless someone picks it up and complete the backport to the artist lbrary. I will try my best to keep it synced to main as long as I can.

Tell me if you are still interested, so I can plan ahead. I might do it (complete the backport cairo_2023 to the artist lbrary), depending in time.

[eakoli]

So what is the actual state of cairo_2023, is it essentially up to date with the main line, but using cairo instead of artist?
Such that if a cairo backend was provided in a similar manner to how the macOS quarts is provided, then cairo_2023 would no longer be needed? (thats actually the preference on my side, as currently the application uses cairo on all platforms, and I would need to ensure compatibility with all the existing UIs as its being switched over).

[djowel]

So what is the actual state of cairo_2023, is it essentially up to date with the main line, but using cairo instead of artist? Such that if a cairo backend was provided in a similar manner to how the macOS quarts is provided, then cairo_2023 would no longer be needed? (thats actually the preference on my side, as currently the application uses cairo on all platforms, and I would need to ensure compatibility with all the existing UIs as its being switched over).

Yes. The cairo_2023 is up to date with the main line, but using cairo instead of artist.

And that is also correct: if a cairo backend (in Artist) was provided similarly to how the macOS quarts (and Skia) is provided, then cairo_2023 would no longer be needed.

I still have some fondness for Cairo, to be honest. But there's a lot to do in various aspects, and I'll need help from equally interested parties in different areas, including that one.

[eakoli]

Ok. over the break I will start looking into how the macOS quartz is done and see if I can get a cairo backend working.

[djowel]

I already started a Cairo port, in fact. It's in the cairo_port branch. There is also a full test of all the features, properly installed as Github actions.

[eakoli]

I assume you actually mean cairo_backport in artist? https://github.com/cycfi/artist/tree/cairo_backport

I guess what threw me was that elements has code branches depending on what backend artist is built with, which seems like that should all be hidden inside artist, otherwise it's not a full abstraction.

Let me know what / where you needs some work done and i'll look into it.

[djowel]

I assume you actually mean cairo_backport in artist? https://github.com/cycfi/artist/tree/cairo_backport

Yes. Sorry.

I guess what threw me was that elements has code branches depending on what backend artist is built with, which seems like that should all be hidden inside artist, otherwise it's not a full abstraction.

I'm not sure what you mean. All abstractions should be hidden in Artist. If not, it needs to be fixed. Can you point me to what you are saying?

Let me know what / where you needs some work done and i'll look into it.

Perhaps we can go through the code. It's faster that way. Video call perhaps?

[djowel]

I guess what threw me was that elements has code branches depending on what backend artist is built with, which seems like that should all be hidden inside artist, otherwise it's not a full abstraction.

I'm not sure what you mean. All abstractions should be hidden in Artist. If not, it needs to be fixed. Can you point me to what you are saying?

Oh do you mean the element's cairo_2023 branch? If so, that is a temporary branch pending completion of the back port to Artist.

[eakoli]

I'm not sure what you mean. All abstractions should be hidden in Artist. If not, it needs to be fixed. Can you point me to what you are saying?

Elements has conditional compilation here depending on which backend artist is using. https://github.com/cycfi/elements/blob/master/lib/host/macos/base_view.mm#L345-L411

Perhaps we can go through the code. It's faster that way. Video call perhaps?
Sure.

[djowel]

Elements has conditional compilation here depending on which backend artist is using. https://github.com/cycfi/elements/blob/master/lib/host/macos/base_view.mm#L345-L411

That is not user code. That is just setting up the host! And the hosts are platform specific anyway.

OK, but granted, you can argue that the #ifdef is still in elements. But you can see that that is only a single, localized code that can easily be abstracted, right? Can you point out any other code, especially one that is pervasive or, worse, required in user code?

[eakoli]

Yea, not in elements end user code, just in elements itself.

I think thats the only area, so ideally all that is managed inside artist, so that the elements code (or implementor of the host) just initializes the artist surface providing the platform 'surface' (hwnd, CGContext, etc) so that there isn't any knowledge of the artist backend in the code that uses artist.

As I would hate to have to add #ifdef ARTIST_CAIRO blocks for each platform once artist supports cairo.

[djowel]

Yea, not in elements end user code, just in elements itself.

I think thats the only area, so ideally all that is managed inside artist, so that the elements code (or implementor of the host) just initializes the artist surface providing the platform 'surface' (hwnd, CGContext, etc) so that there isn't any knowledge of the artist backend in the code that uses artist.

As I would hate to have to add #ifdef ARTIST_CAIRO blocks for each platform once artist supports cairo.

Fair enough. What you are saying makes sense.