Hi Tomaž, hi Noel, Tomaž Vajngerl wrote: > On Mon, Apr 13, 2020 at 7:46 PM Noel Grandin <noelgran...@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
signature.asc
Description: PGP signature
_______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
