SOLVED: How to deal with "Failed to launch GPU process"?

[joachimdurchholzsix]

So... good news here!
TL;DL: Everything is fine

The issues we were having were sorted out, so it all works.
In particular, "Failed to launch GPU process" is gone - no idea why exactly, initialization code was a bit shaky but the message disappeared as we cleaned that up.

We still have some issues; java-cef can do very little about them, so this is just for your information:

a) We are integrating java-cef into our own framework, which uses Javabeans. Which assume that you can change every configuration aspect after the fact, by calling a setter; however, java-cef cannot change some configuration settings once CEF stuff is up and running, so we had to reconsider the architecture. In the end, we had to use separate classes for each configuration variant; if that runs into a combinatorial explosion with too many configuration settings, we'll have to rework java-cef so we can take down the browsers and reinitialize them, to the exact state they were in before.
So my wish would be that java-cef
- either never adopt more configuration settings that cannot be changed after the browser started
- or offer a way to capture the entire browser state, and that mechanism is a part of the core feature set so we can assume we can use this approach in the future. (I won't be surprised if that is completely not feasible; OTOH maybe Chromium does indeed have that kind of feature and it's just a matter of making it available, so I figured I should mention that possibility even if I don't have my hopes up)

b) We are struggling a bit with Mac integration. I believe we don't have any serious problems there, we just need to identify and follow the rules (which are pretty restrictive on Mac I learned, I dimly recall java-cef is already using them so it's mostly being careful about not doing anything stupid).
I'm not working on that personally, if the colleagues run into serious trouble, he'll post questions, so all is fine.
I do feel that java-cef should be a bit more transparent about the way it finds its libraries. Either more explicit Javadoc, or a more transparent load mechanism. That's just a heads-up for now so you know that this area may need improvements; if I ever have an opportunity to do a deeper dive into the load mechanism (which I know is there and overridable), I'll come around with actionable improvement suggestions, but please nobody hold their breath for that. (Mail me at joachim.durchholz@six-group.net if you do your own improvements and want a review, that I can always do.)

[magreenblatt]

java-cef cannot change some configuration settings once CEF stuff is up and running

What configuration settings, specifically, do you want to change? Are you trying to change the settings on an already existing CefBrowser?

[joachimdurchholzsix]

java-cef cannot change some configuration settings once CEF stuff is up and running

What configuration settings, specifically, do you want to change? Are you trying to change the settings on an already existing CefBrowser?

Yes, that exactly. I know that that won't work

Background: the browser is deserialized by first calling a parameterless constructor, then by calling property setters, with no final "build it now" call.
I.e. all bean properties are supposed to be updatable post-construction.
So there are two (actually three now that I think about it) options:
1) Don't expose the configuration as bean properties (not settable ones anyway). So the browser has to be created in the constructor, and since the constructor is parameterless, the configuration parameters need to be static - which means we need a separate class per configuration. Not a big deal today but we may run into combinatorial explosion because we need a separate class for each combination of config values.
2) Make it so that the configuration can be changed post-construction. Either by recreating the browser, or by lifting the restriction on config parameters.
3) Extend our deserialization framework so it has a build() call, which turns configuration parameters read-only and creates the browser. We'd prefer not to do that because we have situations where users can edit all properties, including those that change the browser configuration, and they'd get a browser recreate in that scenario; but that approach would be acceptable if the other approaches don't work out.

Right now, I don't see a use case beyond (1); IIRC browser configuration is about settings that no user is interested in changing anyway, and we'd simply use a standard configuration for all browsers.
I'm a bit worried about configuration options that might be added to java-cef in the future. If there are some that will be interesting for users, we likely can't continue to use (1) and will have to think about (2) or (3) in all seriousness.