Any idea what this might mean? Looks like something dodgy is going on. We’ve had this report from one of our Mac users, hence raising it in this thread…
Never seen that before. But it’s obviously trying to draw to an out-of-range area of the graphics context.
That shouldn’t ever be possible, but it rings a bell with something that came up recently - it used to be possible to do a setBounds inside a paint() callback, and that could (well… maybe) mess things up sufficiently to get this to happen. I added an assertion to catch that a couple of days ago.
Can’t think of anything else other than memory corruption that could make it go so wrong!
It seems pretty likely that the problem was somehow provoked by having a 2nd monitor in use. The problem has currently gone away for the user in question (!): I must admit that I’ve never seen a second monitor cause a problem, so this is pretty weird!
Anyways, don’t panic: but hopefully the theory that a 2nd monitor is behind the problem might make you think what was beind this at some point!
Can’t really think how a second monitor would affect it… It’s the same Graphics object that’s doing the drawing, regardless of where it’s going to end up. Very odd…
Having been poring-over the implementation of replaceRectRGB in juce_LowLevelGraphicsSoftwareRenderer.cpp, I have a working theory that the app might have passed-in a value of w or h equal to zero for a paint operation…?
Your code pre-decrements w and h values before comparison to zero, so I suspect that this is what triggers the exception. I’ll keep checking!
I don’t suppose this is something that Juce could actively guard against in some future build?
my pre-decrementing should work fine, I’d suspect this is more likely to be that it’s trying to write to an image that’s toasted, or trying to write beyond the edge of an image. Can’t think why though…