Hi Tomaž, hi Noel, Tomaž Vajngerl wrote:
On Mon, Apr 13, 2020 at 7:46 PM Noel Grandin <noelgrandin@gmail.com> wrote:The benefit is that it becomes easier to optimise the copying and moving around of this stuff if it is C++ layers all the way down, with no UNO stuck in the middle of it.
Don't quite see the logic here - I'd hate to lose API, which in principle (if something's missing, bug report appreciated) allows external code to do cool things. The code removal in gerrit IMO is gratuitous, you could simply overload getDrawCommands et al with a c++-only API variant.
Yeah, that looks great to me, but I don't like that dynamic / static loading of svgio library (like we already do in graphicfilter). Ideally svgio shouldn't need to depend on vcl - it just creates the primitives from the svg file, so vcl could just import svgio normally.
Which is another nice side effect, that with UNO you get the necessary dependency inversion for free..
Anyway, an alternative to this would also be to create a XPrimtiive2DContainer UNO interface, which would allow to "transport" the Primitive2DContainer unmodified and wouldn't require that we convert, only on demand convert that to Sequence<XPrimitive2D>. Not sure if this solution is any better...
I like it much better - and if speed is of concern, one can then always dynamic_cast to an implementation class. I posit that UNO per se does not impose any performance penalties (modulo cost of abstraction if the API is crap, and perhaps for synchronisation - but for that, anything graphics will have SolarMutex anyway below the first API layer). Cheers, -- Thorsten
Attachment:
signature.asc
Description: PGP signature