How to disable DirectX in JUCE 8?

General JUCE discussion
1

Hello, I am pleasantly using new JUCE 8
By the way, I am using Vulkan 3D rendering APIs too

So may I ask
How to disable and not use DirectX when developing JUCE 8 app ?

Thank you

2

Here’s how to select between the software renderer and Direct2D renderer for a specific window:

Even if you disable Direct2D for a specific window, Image objects will still use Direct2D by default. You can specify the image type when you create the image:

juce::Image image{ juce::Image::ARGB, 100, 100, true, juce::SoftwareImageType{} };

Matt

1 Like
3

Hello, Matt:

Thank you for your help and kindness
However, I found further issue occurs, anyway when using Vulkan library

I guess, DirectX can’t be initalized when Vulkan library is linked together
I posted a new topic on the newer writing about this in this forum

So I will appreciate if you can help me

Thank you and have a nice day, Matt

4

Is there a way to GLOBALLY disable Direct2D rendering for the whole project?

4 Likes
5

I also would like to globally disable Direct2D. I implemented the above renderer-selection for my main plugin window, but it seems Direct2D is still initialized. Every time I create a plugin window, this takes seconds (potentially because I am loading custom fonts from memory).
I don’t even want to use Direct2D as I don’t like the way fonts are rendered (y-hinting is terrible for the fonts I am using). There are many text rendering settings in Direct2D (::SetTextRenderingParams(..)), but unfortunately the renderer doesn’t let me select any without patching.
It would be nice to have a #define to completely exclude the Direct2D renderer from builds. As it stands this issue prevents me from using Juce8 on Windows.
I am also worried about memory consumption and multi-instance performance with Direct2D.

4 Likes
6

+1.

7

+1

1 Like
8

A #define would be nice!

Our application used to work fine on Windows 7 but with JUCE 8 we get DirectX runtime DLL issues. Since we have only a very simple GUI, there is no need for any fancy rendering, we’d rather avoid linking to DirectX altogether. (Apologies if this is not related to Direct2D!)

3 Likes
9

On what platform do you see these issues? Note that JUCE 8 only supports Windows 10+.

10

Ok, thanks! Apparently, I had missed that.

Since we still need to support Windows 7, we’ll just have to stick with JUCE 7 I guess.

11

Which unfortunately is not an option, because JUCE decided without notice to drop maintenance of JUCE 7 alltogether:

A minimum commitment to backport essential fixes to JUCE 7 is something a user would expect from their paid suppliers.

4 Likes
12

My understanding of backports were that it doesn’t happen, but could be allowed under special circumstances. My assumption here was that it’s up to the user to backport these themselves once they have permission to do so.

This brings up the idea of LTS versions again, but I see why JUCE team might not be so enamoured with such a concept, as where does the funding come for this work from a one-time license fee?

13

That would mean I have to ask for permission in every case?

Also, it is not certain that those patches still apply.

I understand that you cannot support old software in eternity, but there should be a middle ground.

Full disclaimer: the JUCE team was very generous in the past to me, since we share some history at Roli.
However using a framework is also a commitment from the users, which would be nice, if that was a mutual thing.

The current behaviour with the legalities give me zero confidence to move forward using JUCE.

I am sorry to go off topic, but since this is an issue, and it won’t be addressed if it isn’t repeated in several places I see no other way.

3 Likes
14

I don’t think that’s an entirely fair characterisation. Historically, JUCE has never provided patches or support for previous versions of the framework. Although we didn’t say “JUCE 7 support will end”, we are following the same protocol as for previous releases.

This would force us to duplicate a lot of work, especially testing, when backporting changes, and we’d have to maintain additional test hardware for platforms (like Windows 7) that are well past their end-of-life. Essentially, this is a significant amount of extra work that would have to compete with everything else, and would necessarily slow down bugfixes and feature development on the current JUCE version.

To address the current topic: disabling DirectX is a solution to a problem, but it is likely just one of a number of potential solutions. I’d much prefer to identify the problems that users are having, and then work to find the best solution for each of those problems, rather than adding (reinstating) a build-time switch for this setting.

I’m particularly reluctant to keep build-time switches around, as they have a combinatorial effect on the build configurations that need to be tested (we don’t have the compute bandwidth to double the duration of our Windows test builds just to test with this flag enabled and disabled). These switches also make it more difficult to track down bugs, as some bugs may only be present with specific combinations of flags, which users need to include in their bug reports.

To put it another way: build-time switches can be ok in internal libraries. For an internal library, the library only needs to work correctly in each of the products in which it is deployed. So, even if you have a huge number of build-time switches in your library, if you only have three products, then you only need to test the three flag combinations that you care about. This isn’t the case for framework code like JUCE, because users may combine flags arbitrarily. Every combination of flags needs to be tested, and adding a flag doubles the number of tests that need to be run.

All that is to say, ideally we’d fix up the Direct2D renderer such that it works well for everyone. Failing that, we’d add some kind of runtime selector that would completely avoid all Direct2D branches. A build-time switch would be a last resort once all other options have been exhausted.

6 Likes
15

I have low interest in exploring a move to Juce 8 while I am reading about frequent issues people are having with the new DirectX facility. If I could disable that aspect of it while it matures then I probably would upgrade to Juce 8 more quickly. This is having a direct effect on Juce’s revenue if a substantial number of people are feeling the same way as me. So that’s just something to factor into your thinking when considering a global disable option, which of course is only required as a transitional measure perhaps for the duration of v8 for those of us that would prefer to hold back on this major change but still support the team financially and receive bug fixes in other areas given the v7 tree won’t be maintained any longer.

3 Likes
16

It’s possible to switch the current rendering at runtime using setCurrentRenderingEngine, so you can continue using the old software renderer if necessary. Have you tried that? If so, what are the shortcomings of this approach?

I’ve seen a couple of arguments for globally disabling D2D:

  • very large textures can’t be loaded, which makes it awkward to work with filmstrips
  • there may be some performance overhead to spinning up some of the D2D machinery

We have a fix underway for the first issue. I’m yet to investigate the second, but anecdotally performance seems fine here, so it’s possible that any performance issues are dependent on the particulars of individual projects. If this is the case, we won’t be able to fix these issues until we’ve seen some bug reports and been able to reproduce the problems.

There are two sides to this. If we have an easy opt-out, then users might try out the new renderer, decide not to use it, and continue without filing a bug report or giving us any way of fixing the issues they’re seeing. Then, we would end up in exactly the same situation when we decide to remove the flag in the future, because we may not have been able to discover all the issues that users care about.

It’s a difficult balance to strike, but at the moment I’m confident that the D2D renderer is very close to becoming a fast, robust default; and that the best way to finish the renderer quickly is to listen to user feedback and address issues at their root cause.

1 Like
17

I don’t think that will happen, enough people are hungry for the benefits that you’re going to get the bug reports.

What is more likely to happen is that you have people being put off now, not using it at all rather than trying it in their own time, and then when a major issue affecting v7 comes up causing a mass herd migration to v8 is that you’ll be snowed under by new bug reports because we couldn’t test it at our own leisure conveniently and have no way to manage the issue by disabling features.

At the moment it feels like the messaging is along the lines that you know v8 has issues and you’re working on them, and if any issues come up in v7 they’re not going to be resolved. It doesn’t inspire confidence, and we kind of have to just hope nothing really serious comes up while being stuck between a rock and a hard place.

2 Likes
18

We have a group that won’t say what their issues with JUCE8 are, and another group that won’t try it out and goes by whatever the first group says. This is beyond frustrating to read.

This all seems rather weird to me. We’ve successfully transitioned NEXUS5 over to JUCE8 and encountered no major issues. Everything paints much faster. We did the same for our Cloud app. Paints much faster, no major issues.

Same for a passion project I’m working on in my spare time (ultraSID).

Instead of straight up saying what your actual issues with JUCE8 are, you ask for a feature flag. Even when directly asked what your issues are, you again decline to say and ask for a feature flag.

If people here go by what others are saying (“I have problems and don’t want to upgrade”) instead of trying it out themselves (it’s free to use JUCE8 as long as you don’t distribute that version of your product) then we’re at an impasse.

5 Likes
19

We also have a group going into detail about what their problems are, there are plenty of examples of those on the forum. Personally it’s those I am taking notes from.

At time of posting literally the next post in the list is this about pop-up menus not working properly. A candidate fix is in development but not yet deployed. Why would people even experiment with Juce 8 when things like this are so prevalent? I prefer to upgrade frameworks when they appear to be relatively stable, and if major feature additions are the probable cause of issues coupled with an abrupt cessation of development of the prior major version, I think it is reasonable to ask for ways to ease into those major changes.

20

The only one I can think of is not being able to load large bitmaps. That’s pretty bad and should be fixed by making it possible to load them as SoftwareImages via a bool in the loadImage functions.

Any font issues have been tracked to the fonts themselves. JUCE7 made some bad assumptions where JUCE8 treats them correctly now. There is a workaround that strips the font of some metrics, thus making it behave the same in JUCE8. I think JUCE8 is correct here and should remain as is.

JUCE should fix its bugs, not keep them around for compatibility’s sake.