RFC removing the XPrimitive2D (and related) UNO classes
thb at libreoffice.org
Tue Apr 14 11:44:19 UTC 2020
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
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__
Yep, that's true.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 1032 bytes
Desc: not available
More information about the LibreOffice