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 !
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?
But OTOH ControlType::Scrollbar is not one of those handled in that FIXME location, so maybe scroll bars are handled totally differently anyway.
In comment #1, s/part of it/part of the document/
As Skia with Vulkan will replace OpenGL UI rendering on all platforms, it does not make sense to keep OpenGL UI reports open. Details about Skia: https://www.collaboraoffice.com/success-story/implementing-vulkan-capable-libreoffice-user-interface-using-the-skia-library/