RFC removing the XPrimitive2D (and related) UNO classes

[Thorsten Behrens]

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
layer).

Cheers,

-- Thorsten
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1032 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/libreoffice/attachments/20200414/9b1b0605/attachment.sig>