I’m pretty sure that has to do with how the AudioVisualiserComponent is buffering.
Matt
Yeah, there’s some discussion to do with confusion around the implementation here:
I’m wondering what might be a good way to fix it in line with the discussion in these threads.
The code looks a little different than it did at the time that thread was written, but I think the hotspot is still the same, the logic of the pushSample() method:
void pushSample (float newSample) noexcept
{
if (--subSample <= 0)
{
if (++nextSample == levels.size())
nextSample = 0;
levels.getReference (nextSample) = value;
subSample = owner.getSamplesPerBlock();
value = Range<float> (newSample, newSample);
}
else
{
value = value.getUnionWith (newSample);
}
}
One easy improvement is replacing
value = Range (newSample, newSample);
with
value.setStart(newSample);
value.setEnd(newSample);
to avoid calling the Range constructor once every buffer.
Beyond that, I’m guessing it might be necessary to rebuffer and display a range of samples slightly later to ensure constant availability of the samples to be added next to the drawing routine. It’s interesting though that the scrolling is totally smooth on Linux and macOS but not on Windows though.
As an aside, in other recent work, I noticed Windows Audio having inconsistency wrt latency reported using the same AudioLatencyDemo, and this is not observed on the same machine running macOS or Linux. You could run the same latency test again and again and get slightly different results each time, with a skew of about 5 samples.
Ah I think I’ve figured it out - it was to do with the refresh rate being hardcoded to 60 Hz. Trying it at 30 Hz allows it to not stutter. So I guess the solution will be to expose the refresh rate to a higher layer and figure out which scenarios require the lower rate.
Can you post another link to a fresh version? It’s easier for me to test that way.
Sure, although I just realized that I broke VBlankAttachment.
This should fix the alpha issues you reported, which also fixed setting the bitmap interpolation quality. I added a combo box to select low, medium, or high interpolation quality.
Matt
This all works really well now. The only thing I find confusing is that when switching to the “widgets demo”, the paint duration stats seem to be updating over and over, even though I’m not even moving the mouse. Are you repainting the entire window at every v-blank?
If yes, can that be avoided? I would like to continue to update only the dirty rects, so that our mostly static displays/components don’t waste unnecessary paint time.
This all works really well now.
Cool.
The only thing I find confusing is that when switching to the “widgets demo”, the paint duration stats seem to be updating over and over, even though I’m not even moving the mouse. Are you repainting the entire window at every v-blank?
The widgets demo miscellaneous page runs a timer at 10 Hz that triggers repaints even if that page is not visible. The stat table itself has a timer for repainting at 5 Hz. I think that’s what you’re seeing.
If yes, can that be avoided? I would like to continue to update only the dirty rects, so that our mostly static displays/components don’t waste unnecessary paint time.
Agreed - implementing the dirty rectangle clipping was a big part of the effort here. It makes a huge performance difference.
JUCE_ENABLE_REPAINT_DEBUGGING still works. I tried building the demo with repaint debugging enabled; while that does demonstrate which window areas are being repainted, it’s quite unpleasant to look at for the big animated areas that are constantly repainting.
Let me see what I can do. Thanks for taking the time to test all this.
Matt
1 Like
Alrighty then:
The “Misc” tab for the widgets demo will only run a timer when that tab is visible.
I moved the stats table into a separate floating window so it can repaint without affecting the stats for the main window.
Matt
This works beautifully. I have no issues; everything seems to be working as expected.
Thank you so much for this.
Is this in discussion for eventual inclusion into JUCE? Maybe for 8?
1 Like
Yes it’s in discussion.
Should we decide to include it then I think that would likely be the aim.
3 Likes
Thanks @reFX; that’s really nice to hear.
Also thank you for testing the demo and for the solid bug reports.
Matt
2 Likes
With JUCE team holidays and lining up an imminent 7.0.7 release, things are, unfortunately, moving a little slowly at the moment. I’m hoping we can share some more information in mid September.
2 Likes
So maybe I’m a little naive here, but since JUCE already has the completely unusable and broken D2D LowLevelContext for years now, wouldn’t it make sense to merge this new version right now into the development branch of JUCE 7, so interested parties can play around with it and give feedback?
Then Matt can fix bugs, make adjustments, etc., before merging into master for JUCE 8?
This way, we at least have something to work with, and since the current implementation is broken, merging it is risk-free. It’s not breaking anybody’s project, since nobody is using it. Remember that you have to enable it by setting the render manually in your code, so it’s literally impossible to break existing projects unless somebody opts in.
Or maybe create a new branch called “d2d”, and make it auto-merge with the “develop” branch, so people can make the decision to use the unsupported “d2d” branch instead of the unsupported “develop” branch?
I’m just very eager to try this for a private project which uses large, zooming bitmaps and could really benefit from hardware acceleration.
9 Likes
BTW, I can not reproduce that with my drivers/hardware. Both are roughly equal.
We are not going to merge anything into our public branches, even behind a feature flag, without a fairly thorough review by the JUCE team to make sure there are no blockers, or otherwise overly disruptive changes required. At the moment we’re a little busy covering team holidays and other work that’s already in progress, so we can’t do this immediately. Apologies - I realise this development is exciting!
Following a review we’ll have a much clearer idea about what the best path to eventual incorporation into JUCE looks like and we’ll report back.
2 Likes
I’m 100% in support of the JUCE team reviewing the Direct2D renderer.
In the meantime I’ll do my best to keep my fork synced with the JUCE develop branch.
There’s still more to be done in any case. I’ll post more shortly.
Matt
1 Like
OK, good to know; maybe it’s a difference with display adapters or the driver.
Matt
Hi matt,
Thanks for creating this. I’m following your work from a year. I really need an improved software rendered for Windows. In fact the main reason I didn’t upgrade from Juce 6 to 7 is it doesn’t solve this.
I’ve tested on my computer your demo 1.03 version. And these are my numbers. I’ve a Nvidia 1050Ti, Windows 10 Professional. Graphics demo, Path Radial gradient
Direct2D: Paint duration 12.3, interval 17.3
Software: Paint duration 7.2, interval 18.7
I was expecting better lower times with Direct2D (it means better, right?). Did I do something wrong?
Hi @juan1979 -
No, I don’t think you did anything wrong. We just need to figure out what’s going on.
Could you please run the DirectX Diagnostic Tool and send me the report?
To run the DirectX Diagnostic Tool:
Start/Run
dxdiag
Click “Save All Information…”
Send me the text file
Or just click Start and enter “dxdiag” and it should come up.
If you haven’t, I recommend you update your Nvidia driver.
Matt
I’m getting 10 times better performance from the demo with the Direct-2D renderer.
NVIDIA GTX980M