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
Attachment:
signature.asc
Description: PGP signature