RFC removing the XPrimitive2D (and related) UNO classes

[Thorsten Behrens]

Hi Noel,

Noel Grandin wrote:
> That is kind of my point - here we have gratutious use of UNO, with
> no real means of an extension using it, which is just making it
> harder to optimise an important of our system.
>
The main point I'm disputing is the 'making it harder to
optimise'. From the patch, nothing prevents you from granting direct,
c++-level access to internal data, _and_ keeping UNO in place.

So without arguing the merits of whether UNO is useful for
drawinglayer/svg, you're mixing two unrelated changes into one patch.

> (1) Unnecessary copying because of UNO shows up heavily in various places.
>     Mostly because we can't pass large complex data directly.
>
Problem of API design. We have examples of complex data structures
wrapped in UNO interfaces (and direct, c++-level access to
implementation if necessary for speed).

> (2) Lots of UNO classes need to have their own Mutex object because
>     they can get called from multiple threads, so it is not just
>     SolarMutex.
>
For graphics stuff, that's a non sequitur - we can just grab
SolarMutex on the outer layer.

> (3) Even where UNO is not itself a perf problem, it introduces
>     indirection because it is much harder to figure out what code is
>     being called and who is calling it
>
That's mostly true for the heavily property-based interfaces for our
document APIs, that then largely affect filter code.

> (4) Touching UNO is an expensive exercise, involving attempted
>     analysis of external usage, awkardness introducing modifications
>     to API, etc, etc (and this coming from someone who __likes__
>     UNO)
>
Yep, that's true.

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/0b3041da/attachment.sig>