On 2020/04/14 12:31 am, Thorsten Behrens wrote:
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.
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.
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).
(1) Unnecessary copying because of UNO shows up heavily in various places. Mostly because we can't pass large complex
data directly.
(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.
(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
(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)
_______________________________________________
LibreOffice mailing list
LibreOffice@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/libreoffice
