I'm wondering what exactly this argument do? and know about potencial downsides that this argument could cause.
I tried searching this VM argument on internet but I couldn't find anything of it.
By default, on macOS JxBrowser initializes Chromium engine in Java process. It's required to support heavyweight rendering mode when Chromium window is embedded into Java frame. In macOS native window from one process (Chromium) cannot be embedded into a native window from another process (Java).
Initializing Chromium in Java process might cause deadlock issues on macOS. It's because SWT, JavaFX, and Chromium share the same Cocoa native thread in Java process.
The java.ipc.external=true VM option tells JxBrowser to initialize and run Chromium engine in separate native process. In this case Java and Chromium don't share Cocoa native thread. It allows solving deadlock issues on macOS platform.
As you may see, in this case heavyweight rendering mode cannot be used. So, in this case only lightweight rendering mode is used. This is the only downside of using this VM option.
Related
I'm trying to port my iOS app to Mac using macCatalyst, and I'm having problem with Siri Shortcuts. The code complies and runs, but when I try to add shortcut using INUIAddVoiceShortcutViewController I'm seeing 'Shortcuts unavailable.'
Using
INVoiceShortcutCenter.shared.getAllVoiceShortcuts returns error [Intents] -[INVoiceShortcutCenter getAllVoiceShortcutsWithCompletion:]_block_invoke Error from -getVoiceShortcutsWithCompletion: Error Domain=NSCocoaErrorDomain Code=4099 "Couldn’t communicate with a helper application."
Any ideas what's I'm doing wrong? Same code works perfectly fine on iOS.
The Intents framework is unavailable at runtime on macOS except for WidgetKit support. The APIs are available at compile time in the Mac Catalyst environment to reduce the amount of changes required to compile for Mac Catalyst. Calling into the APIs as part of the shared code path between iOS and Mac Catalyst is fine, they will just return an error for Mac Catalyst, as you're seeing.
Posted 11 hours ago by edford
https://i.stack.imgur.com/pFR3B.png
Only one error：
08:22:50 FATAL: [0325/202250.082:ERROR:gpu_process_transport_factory.cc(1018)] Lost UI shared context.
It can happen that the Chromium engine can lose UI shared context in some cases. Usually, Chromium will restore the context and continue rendering. In that case, something happened that prevented Chromium from restoring the context.
As a workaround, you can try using accelerated lightweight rendering. It is faster than the usual lightweight rendering and does not use GPU. As a downside, the WebGL functionality will be disabled.
Could you please try enabling the full Chromium logs, reproduce the issue and send them to me? You can enable Chromium logs with the following Chromium switches: --enable-logging --v=1. The output will be saved to the file chrome_debug.log in Chrome's user data directory. Also, JxBrowser logs could be helpful too. You can find how to enable JxBrowser logs using the following link: Logging
In addition, the message you got, can be produced by the Chromium engine when the --disable-gpu or --disable-gpu-compositiong switch is passed to it.
I have a GUI application which contains a websocket server QWebSocketServer. I also have a python script which sends messages and the application processes them. Everything works well. During testing I wanted to run the application in headless mode using -platform offscreen command line argument added to the app executable name (I changed nothing else). But the problem is that when the application runs off-screen, the client script cannot establish connection with the web socket server. I tested this on localhost only. I do not understand how this two things, visibility of GUI and websockets, can interfere. Any ideas what could go wrong?
Note: I am using Qt 5.11.1 64-bit with VS 2017 on Windows 10 Pro.
A platform plugin is a bit more than merely "GUI". The -platform option selects a family of platform-specific plugins. Perhaps some plugins that make networking work are absent on that platform spec. That's very likely, since the offscreen platform is only a proof-of-concept: it's to show how you'd write a platform plugin. It's example code, and it does the bare minimum needed. It's nothing that you should be using for production without fully understanding what's there and how it works - it wasn't not meant for it, at least not the last time I looked at it. It shouldn't be hard to make it work, but you'd need to clone the source and start hacking on it.
I used an evaluated jxbrowser, which version is 6.14, I write an demo to use it. but i have a problem with it.
Use the demo app to start an application, which can show web UI, keep this applciation with opened, but then I start demo app again, system will throw below exception:
chromium profile directory is already/used by another BrowserContext instance or process
jxbrwowser cannot start two clients in one PC? if can, how to resolve it?
We strongly recommend that you don't use several BrowserContext instances with the same profile directory. Chromium engine wasn't designed for such usage and doesn't support it. Even if you don't see any issues right now, the issues will appear later in end user environments. For example, in macOS environment you will get the Chromium's error message dialog every time when you run your application instance developed in such way.
Since it's a critical requirement in the Chromium engine, I don't think we will make it configurable in next versions. This is how Chromium engine works. These is a recommendation we have to follow when working with the Chromium engine.
I have an issue on exported build release from Flash Builder 4.6. The case is when I run it on the IDE(Flash Builder 4.6) it works fine, no issues encountered, it never crashed but when I exported it for a release build and run, it crashes to a certain module/view. The view/module where the AIR app crashes has multiple remote object calls (minimum of 5). I have noticed that when requesting multiple remote object calls(like 5 remote calls at a time) it crashes. Is the remote object causes the crash? Please help me out on this guys, any idea will be much appreciated.
Thanks
Glen
I bet it's a security issue that you worked around when invoking the application from the ide. By default, Flash Builders working directories are marked as "secure", so you don't get any security issues. But when working on the live system, you might need to have a corssdomain policy.
Also: i suggest to use the Thunderbolt logger with the logging framework. This allows you to get log informations straight into your browser's console.