Download it now!
Bug 86249 - clean VirtualDevice constructor ...
Summary: clean VirtualDevice constructor ...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: graphics stack (show other bugs)
(earliest affected) rc
Hardware: Other All
: medium enhancement
Assignee: Not Assigned
Keywords: difficultyMedium, easyHack, skillCpp, topicCleanup
Depends on:
Reported: 2014-11-13 13:54 UTC by Michael Meeks
Modified: 2020-03-12 13:26 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Note You need to log in before you can comment on or make changes to this bug.
Description Michael Meeks 2014-11-13 13:54:09 UTC
The VirtualDevice constructor include/vcl/virdev.hxx has a couple of modes; one of them looks pretty nasty:

     explicit           VirtualDevice( const OutputDevice& rCompDev,
                                       sal_uInt16 nBitCount, sal_uInt16 nAlphaBitCount );

It would be great to check all uses of this method, and see if we can't create a differently named constructor, or even dummy sub-class that has a nicer name - that expresses what we want there. I suspect nAlphaBitCount is always zero if present [ but can't be removed because of ambiguity ].

git grep 'new VirtualDevice'
git grep ' VirtualDevice('

It'd be great to cleanup other calls to VirtualDevice constructors to give them nice names too I guess with thin sub-classes (?).

Thanks !
Comment 1 Robinson Tryon (qubit) 2015-12-10 11:41:02 UTC Comment hidden (obsolete)
Comment 2 Chris Sherlock 2016-02-12 07:02:50 UTC
Hi Michael, what is it that makes the constructor problematic? Could you give some more info?

Thanks :-)
Comment 3 Michael Meeks 2016-02-12 09:44:20 UTC
I suspect the ambiguity is unpleasant - ie. if there are two constructors with similar arguments we should have nice, readable, descriptive enum that distinguishes between the two use-cases; rather than a random number that is always the same value nAlphaBitCount added to the end =)

It seems we have:

ScopedVclPtrInstance<VirtualDevice> pDevice(&aData, Size(1, 1), DeviceFormat::DEFAULT);

I wonder if we could overload something into the vdev creation along those lines; not sure.

Beyond that the bigger problem is that VirtualDevices get created at a 1x1 size initially - complete with OS resources behind them, which are slow & expensive to create - and then we re-size them deleting the original stuff =) really the creation needs to have a smoother flow that passes in the size correctly.
Comment 4 Robinson Tryon (qubit) 2016-02-18 14:51:29 UTC Comment hidden (obsolete)