|
From: James T. <ja...@fl...> - 2022-02-15 13:09:48
|
> On 15 Feb 2022, at 15:01, Fahim Dalvi <dal...@gm...> wrote: > > I came across this today: https://github.com/tqm-dev/ShaderVG <https://github.com/tqm-dev/ShaderVG>, a fork of a fork of the original ShivaVG which seems to not use the fixed OpenGL pipeline (actually I am not sure how to check for this with certainty, but it doesn’t have any glBegin/glEnd calls etc). > > A recent email on this list mentioned that nanoVG may not be super simple to drop in, so I thought to share this here since it seems to follow exactly the same API as ShivaVG. > > Hope this helps! Oooh, yes, it might. The issue is mostly how the different libraries handle clipping. The problem is that for a non-rotated (or strictly, a 90-degree rotated) rectangular clip, you can use glSicssor to clip, which is ‘free’. For arbitrary shaped clips, or where the clip is transformed in some awkward way, the options are A) stencils (which I think is what ‘old’ Shiva uses) B) intermediate framebuffers C) geometric clipping but that’s a royal pain in the ass to combine with gradients / dash patterns BTW this is why you should be super careful about using clips in a canvas: rectangular ones which are only translated / scaled are very efficient (due to glSicssor), but anything else can bite hard, especially on systems where the chosen solution (again, eg stencils) is not a common/fast path. Anyway, I’ll go dig and see what ShaderVG is doing compared to NanoVG :) Kind regards, James |