Support GL raster backend about thorvg

[RuiwenTang]

Maybe my recent commit broke it, I'll check

[RuiwenTang]

@RuiwenTang @SergeyLebedkin Hello, do you mind any anti-aliasing (AA) techniques for GL backend? We plan to implement this with WebGPU and it would be beneficial if the same methodology could be applied. Our primary is MSAA.

I also prefer MSAA which is more efficient in modern GPU APIs like vulkan, metal or WebGPU

[hermet]

@lostminds Thanks for suggestion. Still, it needs more attention and development. Perhaps AA (Anti-Aliasing) should be applied before basic practical usage. I'd like to suggest that you can test for specific drawing contents and then decide which backend engine would be more efficient for your project (rather than fallback mechanism). btw, I'm really wondering the software renderer is not suitable for your project due to performance concerns.

[hermet]

However, in many cases the content will likely be just a lot of simple filled or stroked shapes. And for these cases it would be nice to get something more performant like GPU-based rendering since in this case the more complex features are not required.

I completely understand your point. However, after considering the conditions you mentioned, you can always use the ThorVG GL engine once anti-aliasing (AA) is implemented. Nevertheless, Godot also needs to consider the ThorVG GL version, a topic that has not yet been discussed on the Godot side. Let me look into this further.

[RuiwenTang]

@RuiwenTang, wrt https://github.com/orgs/thorvg/discussions/2048, I think we need to think about the GL integration now. Currently, glCanvas has parameters:

GlCanvas::target(uint32_t* buffer, uint32_t stride, uint32_t w, uint32_t h)

The buffer is not actually used; however, I assume we can replace it with fbo(id):

GlCanvas::target(int32_t targetID, uint32_t stride, uint32_t w, uint32_t h, Colorspace cs)

Basically, we expect the targetID to be a valid FBO, which we can bind inside the GL renderer. If the FBO is invalid or 0, we can probably assume the rendering target is main surface, and we can perform the drawing directly (with no threading).

What do you think?

It looks good to me. 👍

[hermet]

#1531

[hermet]

#1704

[hermet]

@RuiwenTang Radial Gradient fill is a bit different. I remember it worked properly before?

[hermet]

Retaining doesn't updated.

[hermet]

Masking samples appear to be mostly working well, although some background colors are not appropriate.

[hermet]

@RuiwenTang @SergeyLebedkin Hello, do you mind any anti-aliasing (AA) techniques for GL backend? We plan to implement this with WebGPU and it would be beneficial if the same methodology could be applied. Our primary is MSAA.

[hermet]

Condition check:
These are basically working but some minor differences are observed.

• radial gradient: background(bg) color must be black (not gray)
  

• The colors of these masks appear to be somewhat weakened.
  
  
  

[lostminds]

Would it be possible use this faster (I assume) rendering backend in parallell with the regular SW-engine, and have ThorVG automatically pick renderer to use based on what features the content drawn requires?

This way we could benefit from the performance improvements of this renderer for rendering more basic content, while it would fall back to the regular SW renderer in case features are required that the GL renderer doesn't yet support.

[lostminds]

btw, I'm really wondering the software renderer is not suitable for your project due to performance concerns.

My use-case is probably a bit unusual, I'm using ThorVG via Godot in a parametric graphic design app I'm building. It both imports and exports SVG and uses an SVG-like internal format. So I use ThorVG to render a preview of each layer, re-rendering the layers separately on a separate thread when they change and composit them together as textures in Godot. The performance is ok, but could of course be better.

The reason I proposed the automatic renderer selection/fallback-model is that since the content in my case is controlled by the user, I can't know what it will be. It could for example include imported SVG files, so I would like to have as close to full SVG support as possible since fidelity is more important than performance. However, in many cases the content will likely be just a lot of simple filled or stroked shapes. And for these cases it would be nice to get something more performant like GPU-based rendering since in this case the more complex features are not required. But I understand very well that it's a big task, and like you say, getting a good AA solution in place first will likely be needed for any practical use.

[hermet]

@RuiwenTang, wrt https://github.com/orgs/thorvg/discussions/2048, I think we need to think about the GL integration now. Currently, glCanvas has parameters:

GlCanvas::target(uint32_t* buffer, uint32_t stride, uint32_t w, uint32_t h)

The buffer is not actually used; however, I assume we can replace it with fbo(id):

GlCanvas::target(int32_t targetID, uint32_t stride, uint32_t w, uint32_t h, Colorspace cs)

Basically, we expect the targetID to be a valid FBO, which we can bind inside the GL renderer. If the FBO is invalid or 0, we can probably assume the rendering target is main surface, and we can perform the drawing directly (with no threading).

What do you think?