Direct2D Backend

[WindowsNT]

Feature category

• enhancement - build system
• [ X] enhancement - backends
• enhancement - build system
• enhancement - documentation
• enhancement - plot categories

The problem

I'm implementing a Direct2D backend for Windows plotting. The problem is that functions like draw_path, draw_rectangle etc do not have the point size or the color. I 'm happy to share it when it's completed.

The solution I'd like

Implement these callbacks with point size + color. Also, what is the color format of the callbacks like draw_background? ARGB ? RGBA?

[alandefreitas]

I've been implementing an OpenGL backend in parallel, but it's not going as fast as I'd like. I regret doing it with gnuplot in the first place. It created lots of small consistency problems.

But yes, the backend interface needs to be reformulated to work properly with other libraries. It's ok to adjust it. The matplotlib agg backend might serve as a good reference.

[WindowsNT]

Gnuplot is a real mess. I'm editing your source to provide for stroke and correct color passing, hopefully I 'll manage to make it work fine with the callbacks.

[WindowsNT]

Is the callback correctly implemented?

			std::vector<double> t = iota(0, pi / 50, 10 * pi);
			std::vector<double> st = matplot::transform(t, [](auto x) { return sin(x); });
			std::vector<double> ct = matplot::transform(t, [](auto x) { return cos(x); });
			auto plot = ax->plot3(st, ct, t);

This calls my draw_path but the result is a 2D circle, as if drawing in 2D. Do I need to manually create a 3D space? I know how to do it, but how do I get the coordinates to draw from draw_path then ?

[alandefreitas]

Gnuplot is a real mess. I'm editing your source to provide for stroke and correct color passing, hopefully I 'll manage to make it work fine with the callbacks.

Gnuplot is a good tool from the command line. But it doesn't work that well as a library dependency because pipes are very slow and it's difficult to get consistent behavior.

I started working on backends for OpenGL and Vulkan, but while doing that the problem grew and it's kind of becoming a small graphics library to deals with fonts, shaders from expression templates, widgets, .... Regardless of the renderer, there are lots of problems in common to make it work.

I'm also trying to organize it in a way that I could have a third backend to render it directly in a buffer with OpenCL. That backend would work nicely with xeus-cling notebooks, which would be great for scientific computing.

So the current plan became to publish that as a graphics library first and then use it for matplot++. That's why it's been taking a while.

This calls my draw_path but the result is a 2D circle, as if drawing in 2D. Do I need to manually create a 3D space? I know how to do it, but how do I get the coordinates to draw from draw_path then ?

Does the code above create a 2D circle even in Gnuplot? This plot should be kind of a spiral if I'm not wrong. But this result is quite possible with other backends.

In any case, very few axes_objects can send their data points properly to a backend that is not Gnuplot yet. And even the line object used in the OpenGL experimental backend probably has lots of missing features. The opengl example is just a line in 2D.

This is not a problem for Gnuplot but for other kinds of GPU-based renderers, the internal functions to send the data points and the backend API still need to be adjusted accordingly.

There are two reasons for that:

• The backend interface was based on the matplotlib's agg backend, which is only for 2D graphics. Matplotlib made that choice to make plots consistent across backends, but that seems inappropriate for this C++ library, where people want performance. In an OpenGL/DirectX/Vulkan/... backend, these transformations should probably happen through shaders. Another possibility, of course, is to use glm for the transformations in a virtual function whenever there are no shaders to do that. That would allow things like console backends and image file backends while keeping the possibility of delegating these transformations to the GPU whenever possible.
• Another reason is that the backend interface is really just a prototype for the relationship between classes as it is. We had no idea how this API would need to evolve for other backends, so it seemed appropriate to leave like that until the demands for other backends existed.

So that's why we still need to implement functions in the axes_objects to send the data points properly and adjust the backend interface as problems arise.

Sorry if this is more complicated than it seems but on the other hand, the good news are (i) sending data points to the backend interface is much easier than reverse-engineering Gnuplot commands, (ii) the line object can represent most plot types already, (iii) lots of other plot types could currently be replaced by just a composition of line plots, (iv) being able to adjust the backend interface is probably much easier than trying to fit 3d stuff into a 2d agg backend as matplotlib does.

[WindowsNT]

Yes that's my problem, it creates a 2D circle where I 'd need a 3D spiral. It calls my draw_image with a 2D path, not the draw_triangle method.

I appreciate your time.

[WindowsNT]

Also, the whole thing to be implemented in HLSL or GLSL would be better for realtime performance - in my opinion this is not an imminent requirement for the library.

[WindowsNT]

I think that the backend mechanism other than the gnuplot is not complete.
For example, void axes_type::run_axes_draw_commands() ... only draws 2D axes. I guess the library pretty much relies on gnuplot's commands for camera, projection etc. If so, then I cannot use it efficiently.

[alandefreitas]

Exactly. It still needs a lot of adjustments for other backends as it is. This is already in the roadmap and it’ll make it much easier to create new backends. So I’ll close this issue for now but feel free to make any questions, comments, collaborate, or propose any changes.

[KnIfER]

Skia+opengl backend : https://github.com/KnIfER/Textrument-Plugins/blob/main/DirectUILib/SkiaPlotLib/SKiaPlotTest/TestSkiaBackend.cpp

It would be great to see it mature.