We can not provide you with any details unless you give some details first. Just saying “everything I do is so awesome that it can’t possibly be wrong” is again not helpful.
And I just provided an example (hence the “e.g.”) not telling you precisely what is wrong with your code.
You make it extremely hard to help you.
No offense guys but this is super immature.
What is the real issue with taking a week and shipping a minor update which provides backward compatibility while you guys (& also ourselves) solve this long term? There isn’t a tech company in the world which would do a hard swap like this, it’s just irresponsible.
You guys are operating a live platform with a live audience shipping live updates, you don’t have the luxury of acting like this. Running duplicate systems in parallel is just the standard when doing infrastructure changes in any business, it’s not an option, it’s a requirement to evolve.
This is a bit of a tangent but I think it’s an interesting point to make.
It’s curious to see two people mention that apart from the font, these two images are pixel-perfect. They are not and I wonder if this is a matter of the screen resolution or OS that people are using to view these.
They seem to be showing a different approach to resampling. The one on the left is clearly more blurry. The one on the right looks like it has nearest neighbor filtering resulting in sharp edges.
We’ve had a lot of issues like that between retina and non-retina screens with JUCE and ended up having to use GIN resampling library to make sure the plugin looks good on all screens.
For the font size make sure to override
virtual TypefaceMetricsKind getDefaultMetricsKind () const
to return legacy
I’m sorry, maybe I worded my last post the wrong way… it should have been (using a translator): “Such an application is so complex that it cannot be just one thing that could have been implemented incorrectly (but there could be many).”
I mean that if something that was correct for JUCE 7 and is not correct for JUCE 8, can be just one thing (one image, one component) or can be a long series of things.
I was not saying that everything I do is amazing… come on, I’m not that vain!
Anyway, since we build our products around a library, we expect that when the library updates, retro-compatibility is granted, even if some small adaptation is required, but not that the performance drops drastically so that we are forced to rethink and rewrite a big part of the project!
Looks like I’m not the one in need of help… You’re helping me to help you to help me… It’s just ridiculous!
What is the real issue with taking a week and shipping a minor update which provides backward compatibility while you guys (& also ourselves) solve this long term?
“Taking a week, lol.” That’s a level of confidence that I can only imagine is sourced from inexperience, or at least from the perspective of not having much understanding of what is going on, under the JUCE hood.
FWIW, I’ve held back on upgrading our plugins to use JUCE 8 for precisely this kind of situation, and any professional development environment will adopt the same policy.
It makes absolutely no sense to be complaining about a version that is clearly marked as in-development, and then getting your feathers ruffled when asked to participate in that development by providing more information about performance issues being faced JUCE 8 is Not Ready For Prime-Time by any measure, except by the very brave … or naive.
JUCE8-develop is a moving target with a great deal many new wonderful features. The glue is still soft. The joints are still healing. The paint still, very wet. Building against it with the intention of doing a public release is a fools errand - its simply not ready yet.
Get your build working in JUCE7, release your product - and when the dust settles on JUCE8, give it another go. If there are truly breaking fixes in JUCE7 that are fixed in JUCE8, find them out and let us know - all of us, the development community is not just the JUCE team, there are also very many developers in here who are willing to assist with issues like this - if we have enough details.
The suggestion to use Sudara’s perfetto is a really, really good one. It will provide a lot of clues as to what is going on.
And don’t forget, JUCE8 is not just about Direct2D support - that is just a minor aspect of it, in terms of platform and frameworks support. And there are many, many other issues that can be exposed in the Direct2D implementation - not all graphics drivers are the same, nor are assumptions made about the Direct2D pipeline equivalent in all cases. It is a huge ask to have Direct2D support ‘working flawlessly’ within the very first point releases of an implementation.
A framework like JUCE is going to have thorns and warts around the periphery of its scaffolding - this is the nature of a cross-platform, cross-architecture, cross-framework, cross-plugin-sdk library, which is after all, doing a lot of the heavy lifting for you.
Try to have some respect for the cyclomatic complexity that you are, as a JUCE-using developer, being shielded from by the rest of the team, and help them out with real data, not complaints that just rub everyones feathers.
Use it - it really works to find performance issues - and the JUCE core dev team as well as a number of us in the forums, actively participating, can help work out what is going on:
This is why multiple customers have been asking repeatedly for long-term Juce 7 support.
Yes, until something changes in operating system that is addressed in Juce 8 but not in Juce 7 which is obsolete, for example the recent iOS audio driver issue with iOS 18. There’s a fix in Juce 8 (which still doesn’t work perfectly) but not in Juce 7.
Also, this story of the community et al… we pay money for using Juce, and receive an invoice. It’s a commercial product that we buy, not a donation to a charity cause… I don’t expect to receive personal support 24/7 but at least that the Juce personnel (i.e. whoever decides what’s going to be included into a release and what’s going to be left behind) takes action and listens to paying customers. And what I see now is a lot of paying customers facing issues that won’t let them update their softwares because Juce 7 is obsolete and Juce 8 is incomplete.
To be clear I (and I expect the other user) was referring to the screenshot, not the image you’ve shared which appears to be taken with a camera while (according to the OP) using the magnifier application. I can clearly see the difference in this image but I’m suggesting something else could be happening in this particular case.
To explain what I mean, I used an online tool to perform a difference between the two sides of the screen shot I was referring to. From this we can see that almost all the differences are indeed surrounding the text, and even those that aren’t could just as easily be caused by compression artefacts. From that I would conclude that JUCE is indeed drawing to the screen the same in both cases (except for the fonts). However, as you and the OP have rightly pointed out the image shared when using the Magnifier tool is noticeably different so I can only assume that for some reason or another the magnifier tool has some part to play in why that is.
Hopefully that’s clear.
JUCE7 is not obsolete.
JUCE8 is still in development.
Between those worlds, you do indeed need to take responsibility for fixing the bugs in the software you’re shipping.
takes action and listens to paying customers
They have done that - they are actively participating in this thread, and their action is: asking you for more details about the performance issues you are experiencing, but which you seem entitled to not have to report or provide, as feedback, in any productive way other than providing a sarcastic video-based bug report which doesn’t help much, at all.
If you want help, integrate perfetto (its very, very easy) and provide the details. Bonus for you: you’ll be able to use perfetto to find bugs and performance issues in your own code, too.
It’s not receiving new updates… how do you call it? I’m still using it, but I’m now in trouble because some things that don’t work anymore with Juce7 work with Juce8, but what used to work well with Juce7 doesn’t work equally well with Juce8… I don’t know how else I can explain, am I saying something wrong? I apologize in advance for that.
Right… but I should fix my own bugs, I didn’t expect to fix bugs in the library I pay for and that should help me code less and faster. I’m afraid we’re seeing things from different perspectives, but I appreciate your help.
BTW… back to the hot stuff…
I will try… Meanwhile I have used the VS2022 profiler and found that all calls of DropShadow() are indeed slowing down the paints. If I comment out these calls (there are many!), the Juce8 build performs almost like the Juce7 build, at least with all optimizations on.
JUCE 7 not receiving new updates
IMHO, this doesn’t make it obsolete - it is, after all, still perfectly usable for building plugins and apps, and can indeed still be used to ship working software for the environments it targets. It would be obsolete if it no longer produces functioning plugins/apps in the target environments for which it was previously working. The fact of the issue with iOS18 making JUCE7 unworkable is unfortunate, but par for the course where we are all chasing Apple’s (extremely expensive and well-funded) coat-tails … we could as well complain to them for breaking things that previously worked, but hey … you gotta pick your fights. Always remember: to Apple, you’re responsible for all of the code your product uses, even if you licensed parts of it from 3rd-parties yourself.
Perhaps there is some validity to the argument that bug-fixes should/could be back-ported from 8->7, but in most of the cases where its been a show-stopper in terms of shipping distributables to end customers, the effort to do it yourself is pretty low, especially if you have perfetto and other tools at hand to find the bug and isolate the fixes.
Anyway … I know there are a few of us who are maintaining our own JUCE7 branches with fixes and updates in the form of local patches/diffs - perhaps it would be worthwhile getting us organized in a helpful way and coming up with a JUCE-7-community-bugfix-or-backport branch, somehow, somewhere …
However, I see that this is a charged subject and I’ll drop it, since you’ve done the right thing and gone back to finding out the cause of your performance issues, which is mighty helpful both to the official JUCE team, and those of us in the community who pay attention to these issues, also:
DropShadow()
I guess it would help to know what hardware you are testing on, which OS version, what Direct2D version, and so on.
If those are the built-in drop shadows that would explain a lot. Use this instead:
Would be interesting to see if any JUCE devs agree with you on this?. JUCE 8 is 6 months old now. I personally haven’t upgraded immediately for the first time since JUCE 5 due to all the issues. I might expect a few wrangles with a new major version, but not 6 months worth.
“and when the dust settles on JUCE8, give it another go”
just out of intererst, what would you recommend for this? Another 6 months? We’ll be over half way to Juce 9 by then given recent release cycles.
JUCE 8 is 6 months old now.
Yes, that makes it still very young and fresh and not at all battle-tested in any sense, imho.
I think the dust will settle on JUCE8 once the features that are being developed on it, have been validated/verified as having at least been better, performance-wise, than JUCE7 - and as we can see in the forums there are still many sticking points that catch the unwary developers.
DropShadow()‘s seem like a very ill-advised feature, imho, but I have no idea why this was considered a worthwhile use of the core teams’ time and effort …
Interesting. I totally disagree. I guess though as a pay monthly user you haven’t dropped the wedge of cash that indie/pro developers have dropped on something that still isn’t “battle-tested” after 6 months so I guess I can see your viewpoint.
Curious choice of words
Slightly off topic, but worth a mention:
emotions seem to be running a little high in this thread; remember to keep it civil, and in line with the forum rules that I can’t find right now…
Having DropShadow use matt temporary image tweak should probably fix your issues.
We just need to have something similar in Juce8 official repo
We’re working on it
