I’m seeing an issue in release builds only, where dirty views will fail to draw making it look like they are flickering. Anyone else seeing this? Doesn’t happen in debug builds, nor does in happen in Linux or macOS.
Is there a way to disable the new DirectComposition to see if that’s causing the issue?
The following line initializes the direct composition engine. Comment it out and it will use the old variant. vstgui/win32factory.cpp at develop · steinbergmedia/vstgui · GitHub
Let me know if the Direct Composition implementation is the cause of your issue.
The issue goes away when I disable DirectComposition. The view where I’m seeing the issue is being constantly updated in my editor’s notify method before I call frame->idle(). Not sure if that helps. Also, it might be helpful to know that sometimes the view is partly drawn.
Can you try to set CView::kDirtyCallAlwaysOnMainThread to true? Or do you call setDirty from a secondary thread?
SetDirty is being called in my editor’s notify method before calling frame->idle. Setting CView::kDirtyCallAlwaysOnMainThread to true does not resolve the issue.
OK, hmm, never seen or heard anything like that before. We ship a few plug-ins using DirectComposition with the latest Cubase version, not one report about such an issue.
Can you try to isolate the issue? What happens if you remove all other views? How often do you redraw, 30 Hz, 60 Hz or more? Have you checked that only the main thread changes the state of the view?
I’m perfectly content to just disable DirectComposition. I’m sure if there’s an underlining issue, it’ll be reported again when more people start using VSTGUI 4.11.
As a further observation, with idle time set to 5ms (which is unreasonably low for the complexity of drawing involved), I decided to benchmark the performance with and without DirectComposition. In both cases my UI averaged about 15.8 ms / frame. So at least for this particular UI, there was nothing to be gained using DirectComposition. Did you own tests show significant performance improvements?
DirectComposition is not about a performance gain in this case. It’s about the possibility to add layers on top (see CLayeredViewContainer) where you can see performance gains.
But it would be nice if you could isolate the issue so that the issue can be fixed.
Here’s a class to reproduce the issue. Just call setDirty on it before each frame->idle call. I see the flicker within about 30 seconds. Make it nice and big so VSTGUI needs to break a sweat.
class FlickerTest : public CView {
public:
FlickerTest(const CRect& size)
: CView(size) {
}
void draw(CDrawContext* con) override {
int width = getWidth();
int height = getHeight();
if (auto gp = con->createGraphicsPath()) {
CRect r = getViewSize();
r.setWidth(1);
for (int i = 0; i < width; i++) {
gp->addRect(r);
r.offset(1, 0);
}
con->setFillColor(kRedCColor);
con->drawGraphicsPath(gp);
gp->forget();
}
setDirty(false);
}
};
UPDATE: Simplified the flicker test.
Hi,
I tried to reproduce but I’m unable to do so.
I’ve checked in the test on the test-directcomposition-flicker branch on GitHub.
Can you checkout that branch and build the vstgui standalone example and check if this example does the flickering on your system?
Thanks.
Arne,
I’ve checked out the test-directcomposition-flicker branch, but I’m unsure how to build the standalone example as I’m not a cmake guru. The VSTGUI standalone examples are not listed in the vstsdk solution. How do I go about adding them?
I added set(VSTGUI_STANDALONE_EXAMPLES ON) to the vstgui CMakeLists.txt and they are now showing up.
Arne,
So I built the standalone examples, and it’s a mess. None of the ‘Release’ versions do anything, and all debug versions prompt me to save a resources.uidesc file and either crash, or repeatedly ask me to save the same resource file. Please advise.
okay copying resources into the bin directories gets things working. Always a guessing game. How can I be sure the view is continuously updating?
nevermind
It seems to run fine on my Surface book 3, but occasionally flickers on my main development machine (GTX 1050 TI, Windows 10). I’ll see if my graphics drivers are up to date.
Still flickering after driver update.
Oh sorry for not more precise on how to build it. But you can just build vstgui without the VST3 SDK as it is independent of it and if you just build vstgui via CMake you will also get the Standalone examples and they should build out of the box in Release mode without needing to copy anything afterwards. This may be different when building the VST3 SDK.
But back to the flickering, can you checkout my latest change on that branch if it makes a difference? I only changed the uidesc file of the standalone example. Thank you.
Still flickers. My own plugins do not derive from VST3Editor, so I would be very surprised if any changes to the uidesc file would fix the problem.
You should not check your own plug-ins with my changes. Did you check the standalone example? I’m trying to get a reproducible example I can check on different machines with different graphic cards to find a combination that exhibits this issue.
Or you give me the source of your plug-in as an alternative.