Bug 97975 - OpenGL: theme / widget cache ...
Summary: OpenGL: theme / widget cache ...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: graphics stack (show other bugs)
Version:
(earliest affected)
5.1.1.1 rc
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: difficultyInteresting, easyHack, skillCpp, topicCleanup
Depends on:
Blocks:
 
Reported: 2016-02-18 11:51 UTC by Michael Meeks
Modified: 2017-02-14 08:57 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Meeks 2016-02-18 11:51:00 UTC
The OpenGL code has a nice cache for storing transparent OS rendered themed elements. Unfortunately the keys used to lookup items in this cache do not contain all of the necessary information:

Checkout:

git grep ControlCacheKey

The problem is that the drawNativeControl methods (eg. in WinSalGraphics) - takes an ImplControlValue parameter. This parameter can have a ton of state rammed into it (checkout the sub-classes in include/vcl/salnativewidgets.hxx). While the cache is keyed on one 16bit ControlState parameter - in fact some controls have multiple child controls with different states =)

Take for example a CTRL_SPINBOX - it has two sub-buttons, each with a different state - checkout SpinButtonValue - which has an mnUpperState and an mnLowerState.

This explains the FIXME: in the salnativewidgets.hxx - "these guys have complex hidden state" ...

Ignoring that state then breaks things like eg. mouse-over of a spin-buttons' "up" button doing a nice pre-light of that control etc. since it is indistinguishable in the cache.

So - in order to re-enable a number of these via mending 'canCacheControl' -  and improving rendering performance - we need to include the ImplControlValue (and its comparison into sub-classes) into the ControlCacheKey. How best to do that is not particularly clear - perhaps getting a 'virtual sal_uInt64 getExtraState();' to the base-class, and then combining the ControlStates into that (not many bits are truly used in that so it should fit). It should only be necessary to combine the various states into that guy.

So - adding a new sal_uInt64 to the ControlCacheKey and populating it from a new virtual method in every ImplControlValue sub-class, and then re-enabling CTRL_TABITEMS, CTRL_SPINBUTTONS, and CTRL_SPINBOX's caching ? in 'bool canCacheControl'

Does that look sensible ?

Thanks !
Comment 1 Tor Lillqvist 2016-08-22 09:38:05 UTC
Not sure if a single 64-bit extra state is enough to distinguish all possible visualisations of for instance a scroll bar? Doesn't the display of the "elevator" (slider?) thing in a scroll bar depend on not only the position of the scroll bar but also how large part of it is visible, in some themes/styles at least?
Comment 2 Tor Lillqvist 2016-08-22 09:47:29 UTC
But OTOH ControlType::Scrollbar is not one of those handled in that FIXME location, so maybe scroll bars are handled totally differently anyway.
Comment 3 Tor Lillqvist 2016-08-22 09:49:05 UTC
In comment #1, s/part of it/part of the document/