Yep, judging from the screenshots and description the customer sent, this seems to be exactly the same issue. I wonder, why does it differ between VSTGUI versions, though?
I wonder why the proposed fix work different then how the current version works. I would expect the VSTGUI HWND to be back buffered so that when another window covers it and is removed, that it does not need to redraw at all. Looks like that these hosts do something really different with its top level HWNDâs then the others.
Hi Arne,
I donât know, either. Maybe an ugly workaround I could try in the client code is invalidating the entire frame, everytime the plugin window is brought to the front (?). That wouldnât remove those glitches when the window is in the background, but at least that would make the GUI work properly when itâs in the foreground and it wouldnât hurt, either.
Can you enlighten me though, why the respective section in win32frame was changed in the first place?
Thanks.
I think the change was made to prevent calculations when only one rectangle is dirty. So basically an optimization. I still think that it must work as is after I checked the code and the Windows API documentation.
So it does no harm to revert the change to get it working, but Iâm puzzled why it does not work as is.
Okay, what do you think about offering an optional configuration flag that can be passed to win32frame via CFrame::open(), like the kNoCALayer on macOS that allows for switching between the two variants? Something like kNoWMPaintOptimization.
I already changed the code so that it should always work now: fix redraw issue with some hosts and simplify dirty region handling ¡ steinbergmedia/vstgui@296fdea ¡ GitHub
Ah, thatâs great news. Thanks for the fix and the heads-up, Arne.