elements artist port

[SeleDreams]

Hi, I am pretty satisfied by the new possibilities opened by the port of elements for dpf, however I notice that the version that got ported is the cairo version which isn't the most efficient performance wise. The artist port branch of Elements uses Skia for rendering which is more efficient since it relies on OpenGL https://github.com/cycfi/elements/tree/artist_port I'm wondering how hard it would be to update the port to use the skia version instead ?

[falkTX]

skia uses gtk which is not suitable for plugins, plus gtk uses GPL as its license which does not allow self-contained proprietary plugins (using LGPL means we would need gtk to be a shared lib, not static lib, but that breaks plugins)

so we need to rely on the old cairo based code.

[falkTX]

I mean it uses gtk on linux, not an issue on other systems where it integrates with the OS level APIs. But DPF is meant to be safely used in a cross-platform fashion, do not want to make yet another win/mac only codebase, there are many for that already.

[SeleDreams]

Actually, I spoke with the core contributor of elements and they said that it is planned to move away from gtk, so I guess it will be possible once it will be done

[falkTX]

gtk comes from skia, not from elements. or is the idea to not use skia after all?

I think the initial idea from them was that cairo was unmaintained, but that is no longer the case. they already spent quite some time on the skia port, so hard to imagine they will move away from it.

or maybe you mean skia might not use gtk at some point?

[SeleDreams]

I spoke more with them and I got told that gtk does not come from skia

[falkTX]

oh errr that is even worse then. skia uses gtk on linux, so then on the elements artistic branch they also directly call into gtk? that would solve one issue if they move on to use something else, but then there is still skia making use of gtk that becomes a problem.

[falkTX]

seems I was wrong, skia does not use gtk, seems it does not do any event/windows handling? so then elements and dpf could potentially work assuming they limit their gtk use.

dpf already provides the event handling and window creation, we take out that part away from the elements code and inject our own. so in theory doable..

[redtide]

AFAIR:

elements uses a 2d drawing engine to paint their widgets on a surface (via cairo or artist) and take care of the event handling providing a native widget toolkit based event loop implementation.

Artist is an own drawing engine interface that works on top of different backends: skia for linux and windows and quartz on macOS.

So elements requires what they call a host (the backend of the underlying widget toolkit) to paint their widget elements on top of it via drawing engine (win32 HWND, cocoa NSWindow or GdkWindow).

What was done with sfizz initially was to replace the GTK implementation with a custom host using PUGL, but due some issues was replaced later with VSTGUI. What DGL (right? or DPF Widgets) should do is have its own X11 implementation (via PUGL?) to provide a surface where elements can draw its widgets, basically a custom X11 host.

[falkTX]

What DGL (right? or DPF Widgets) should do is have its own X11 implementation (via PUGL?) to provide a surface where elements can draw its widgets, basically a custom X11 host.

correct, and this is already what happens. it is still via pugl, but we can customize the build as needed too because pugl is used as vendored dependency with extra files for any missing functionality. this is what allows the web-assembly + webGL to work.

as long as the elements API allow to have a custom "host" implementation, DPF can hook into that and provide all the custom event and window handling. this is what the current branch on this repo does, based on pugl cairo code.

for going with skia/artist branch of elements, we need to implement skia surface support into pugl, so it gives us a skia context to write into. but this shouldn't be much of a problem as from what I can see it will be a similar approach to what cairo is doing, just using a little different API.

[redtide]

OK, so I think that is where collaboration/contribution should start: by providing a dgl host for elements (as a side note, at some point rename the linux one to gtk3).

[falkTX]

dgl is part of dpf though, so we would get into a circular dependency if we include dgl on elements side. the target is the other way around, have elements provide a generic host interface and we keep the dgl/dpf implementation here, vendoring whatever is necessary for such builds for a 1-stop solution

[redtide]

Back to this, I recall that also jpcima had to deal with circular dependency, but IDK what you mean with generic, AFAIK the elements host implementation should know the widget/window type used by dgl, like as example it does with gtk.

[falkTX]

I mean I do not want to have elements depend on dpf in other to use it, the dependency order should be the other way around. So a dedicated dpf widget would depend-on/use elements which then does not have any other dependency back to dpf.

We can have this by having a generic/dummy/stub like interface on elements side, which implements hooks to get the platform level stuff done. it is kinda already like this but hardcoded to gtk or cocoa. see https://github.com/cycfi/elements/blob/develop/lib/include/elements/base_view.hpp#L294 A first step is to add a generic compiler macro to allow a custom implementation there without relying on anything at all on elements side. The whole point is to have an implementation be outside the official repo.