Just wondering if anybody else is seeing this:
I have not been able to create a minimal program to reproduce, nor have I been able to prove it isn’t a bad merge with my fork of juce. It has something to do with opaque components, but not sure what yet.
Looking at the behaviour I don’t think this is the issue but just to be sure can I check you definitely have this commit? https://github.com/juce-framework/JUCE-dev/commit/cea19a9d120d6e43321d8e71ecbfe77a4966bd0f
Assuming you do have that commit, the thing to start looking at is the calls to getNonObscuredBoundsFor() in paintComponentAndChildren().
One thing I might suggest is doing a binary chop to find just a single opaque component with the issue (if possible). Go through all your opaque components set half to not be opaque, see if the problem goes away, if it doesn’t, find the next half to flip, if it does go away try switching half of the ones you switched off back on, keep doing that until you find ideally just one opaque component causing the issue. This will hopefully keep the debugging simple.
Alternatively it looks like it might be quite clear which components are not painting because they have concluded they are covered by an opaque component. This might also help debugging you’ll either find that
There are a few other things running through my mind to look at but lets start there and see where we get to.
I don’t have these issues with the official development branch in my hobby project. So I assume it’s a merge issue.
@RolandMR don’t know why I didn’t think of this yesterday but can you check the new Component unit tests are passing for you? if not then I think we can confidently say it’s a merge issue. If they are passing then I suspect we have a slightly more complicated interaction occurring.
So this has bitten us in a pretty serious way:
I’m almost certain it’s this commit that’s the culprit as the one before doesn’t exhibit the problem: Component: Improve opaque component checks · juce-framework/JUCE@961ff32 · GitHub
The problem is that we can’t just roll back though as we need the newer CoreMidi: Fix timestamps for incoming MIDI messages commit.
Thanks for reporting.
For now we’ve reverted the changes causing this issue. We’ll reintroduce these changes with a relevant fix at a later stage.
The changes have now been reintroduced with fixes for the reported issues. Thanks again for reporting.
Looking good so far, I’ll get a build into beta testers hands so they can bash on it a bit more
Thanks @RolandMR let me know if you notice any performance improvements or issues too.
I see a problem but don’t have a moment to roll back and compare commits.
In the DemoRunner, when selecting:
GraphicsDemo
Lines
the end result is flickering and some other unexpected issue(s). I’ve tried the others with various configurations/settings; this is the only weird piece.
Tested with Xcode 26.2.0.
@jrlanglois thanks for reporting I can reproduce the issue you are referring to (although I don’t need to enable “Higher quality image interopoation”). I’ve checked and this at least exists on master which means this issue is not caused by the above commit.
@jrlanglois the oldest version I’ve been able to test is 5.4.6 and the issue exists there! Is this causing an issue for you or is it just something you stumbled upon?
Looks like this one goes way back! I don’t have a real-world app example since I’m mostly out of this space now.
My main intent was just to give a quick sanity check and see what, if anything, has practically changed for myself.
Consider this just a flagging while poking around.
