RFC removing the XPrimitive2D (and related) UNO classes
thb at libreoffice.org
Mon Apr 13 22:31:12 UTC 2020
Hi Tomaž, hi Noel,
Tomaž Vajngerl wrote:
> On Mon, Apr 13, 2020 at 7:46 PM Noel Grandin <noelgrandin at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 1032 bytes
Desc: not available
More information about the LibreOffice