Re: RFC removing the XPrimitive2D (and related) UNO classes

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)