There’s an issue with bitmaps that have a width and/or height of >=32768 pixels on Windows which has been the case ever since you switched to the Direct2D backend. CBitmaps with a greater size will be decoded and initialized properly (the underlying platform bitmap has the correct dimensions, a data pointer and so forth) but simply won’t be displayed by the Direct2D implementation of CDrawContext::drawBitmap(), which is annoying when using HiDPI graphics and e.g. a CAnimKnob because you quickly hit said size limit.
I have, however, arranged with it as it seems to be some internal/undocumented restriction in the underlying D2D API that performs the drawing. We’re talking about VSTGUI 4.9 here.
Now here’s the thing with VSTGUI 4.10 and where it starts to get a little complicated: In VSTGUI 4.9 there is an optional static function that allows to enable hardware accelerated rendering, i.e.
useD2DHardwareRenderer(). I experimentally enabled the hardware renderer and noticed the size limit drops to <16384 pixels and thus never used it.
I see that this feature has moved into the PlatformFactory implementation, namely
Win32Factory::useD2DHardwareRenderer (). However, some debugging revealed that this setting is not respected unless the underlying draw context is created using
D2DDrawContext::createRenderTarget(), which under normal circumstances isn’t the case.
It seems that draw contexts bridged through
Win32Frame::paint() always have hardware rendering enabled implicitly which seems to have something to do with the switch to direct composition. In other words, in its current form VSTGUI does not support bitmaps with sizes >= 16384 pixels on windows regardless of the setting applied through
Can you please look into this?