Hi,
As the tittle say, when updating a small component each idle, the CPU become very high if the background image of the plug-in is quite big. Checking it deeper, I saw the following steps:
_ the small component invalid() function is called
_ this imply this small component to be redrawn
_ this redraw is called by CViewContainer::drawRect with the small component size.
so far so good.
BUT
_ this CViewContainer::drawRect is called from CFrame::drawRect , updateRect being the full plug-in size.
This means that each time the small component is updated, the full plug-in background is redrawn which is a problem with big size UI.
Is there something I missed ?
Thanks in advance for your answer.
Best regards
Xavier
Under normal circumstances this should not happen as described.
On which OS and version are you seeing this?
Thanks for your answer
I’m working with VSTGUI 4.9 (August 2020), working on OSX 10.11.4 with XCode12.
Tested and debug with Cubase 10.
My code for opening the plugin and adding the component is about the following:
bool Plugin::open (void ptr)
{
CRect TailleImage;
CFrame newFrame;
frame = NULL;
AEffGUIEditor::open (ptr);
…
newFrame = new CFrame (TailleImage, this);
newFrame->CFrame::open(ptr);
…
mframeEdit = newFrame;
mframeEdit->setBackground( MainBitmap ) ;
VuMeter = new CVumeter(..); // (derived from CControl)
mframeEdit->addView (VuMeter);
addParameterListener(Handle,VuMeter);
}
Best regards
Xavier
That’s an old OS. But anyway if I remember correctly VSTGUI should not behave like you have observed on that version. You now have to find the reason why the updateRect in Frame::drawRect is the full rect of the plug-in. First check if the full rect is coming from the system in NSViewFrame::drawRect. Step through the code and see where the updateRect get’s the size of the plug-in. If it’s already at this point, you have to check all calls to NSViewFrame::invalidRect() where they are coming from and check which code path is responsible for invalidating the whole plug-in area.
Oops sorry, the OS is 11.4 (Big Sur)
NSViewFrame::drawRect is called with the full plug-in size, but NSViewFrame::invalidRect is only called with the correct small component size. Anyway, I will make more test on the later point.
After more tests, I confirm that CFrame::invalidRect meaning NSViewFrame::invalidRect is never called with the full plugin size (apart once when the UI is opened) but always with the small component size when this component->invalid() is called.
So I still wonder.
Best regards
Xavier
Sorry for bumping this, but I can’t find the solution.
On Big Sur, CFrame::invalidRect is correctly called with CRect& rect corresponding to the small component size, but just after (and I’m sure this comes after the previous invalidRect) , the CViewContainer::drawRect coming from NSViewFrame::drawRect is always the full plug-in size.
I tested with again, and this is working fine.
Does my problem come from the way I add the component to the frame ?
Cframe* frame;
…
frame->addView(PteViewComponent);
Thanks again for your help.
best regards
Xavier
The system is combining multiple dirty rectangles to one in some circumstances? Are you invalidating other areas at the same time?
Indeed I thought about transparency and overlapping views.
But to be sure this is not the case, I created a very simple UI: a big background (width far bigger than 700 px) and a small view (width far smaller than 700 px), updating every idle.
I also changed CFrame code for putting breakpoints (see below)
These breakpoints were never raised after the full view was drawn once.
Meaning, the invalidate always occurred with the small component update, the drawing always occurred with the full plug-in view.
According to the small view update during idle, the breakpoint in drawRect should be called each time.
So I really doesn’t understand that.
Best regards
Xavier
CFrame::invalidRect (const CRect& rect)
{
if (rect.getWidth () > 700)
{
TestBreakPoint++;
}
…
}
and
CFrame::drawRect (CDrawContext* pContext, const CRect& updateRect)
{
if (updateRect.getWidth () <700)
{
TestBreakPoint++;
}
…
}
I’m still digging with no success: Within the same project, I replace the original UI with a very simple interface: one background image (the one used by again) and one vu-meter updated every idle. So I’m sure there is not overlapping images, with transparency (and Im sure this doesn’t come from the png)
Same result.
So I wonder if there isn’t a define somewhere to be set, or something my project doesn’t have.
Very weird indeed!
How about changing the UI of the again example to the UI you use in your plug-in? If it is still working correctly in again then you really have some weird setup issue.
Hi Arne,
Actually, instead of downgrading my project, I created a new one based on an old version of the again example (from vst3 sdk 3.66)
The result is the same.
So again from 3.73 (using the editor) is working fine whereas this updated again from 3.66 (but using the 3.73 sdk) is not working as expected.
I’ll now compare these two project for trying to find what differences make this. But that really weird.
After loading the two plug-in side by side on Cubase, I can see a difference from where the VSTGUI_NSView_DrawRect is called.
With the 366 pug-in, it’s called directly from the OS, with the 373 plug-in, it’s called from a lot of cocoa functions (the last one being NSView _recursive:displayRectignoring …)
So I guess the problem is coming from this and how the UI is created and attached.
The view is created the same way in both cases, but VSTGUIEditor::attached is called from different OS path.
I don’t who is responsible to call VSTGUIEditor::attached, and why is done differently with these two plug-ins.
Here are the stack for the two plug-ins when the view is attached (launch by Cubase 10, Big Sur, XCode12)
Thanks again for your help
Best regards
Xavier
Hi Xavier,
I’m sorry but I don’t get the difference in the two images you posted. For me it looks the same.
Can you post full backtraces (no images please)? You can get it in the debugger console by using the lldb command bt.
Hi Arne,
Actually this stack differences was a wrong hunch.
The official again project I built was done with VSTGUI 4.10 (dated August 5th, 2021), the one I built used the 4.9 version (dated August 20th, 2020).
After migrating to 4.10, everything worked fine with again.
Furthermore, after adding minor changes required by 4.10 on my plug-ins , they are working fine too. Only the small component are redrawn as expected.
You know more than me the differences between 4.9 and 4.10 so might understand why I’ve this issue. But As it’s fine with 4.10 I will go this way.
Thanks again for your help.
Best regards
Xavier
Ah OK, I’m not aware of a change that this behavior would fix. So it must be a side-effect of another fix.
But I’m glad that this fixed your issue then.
