发布日期 2020年08月14日

JxBrowser 7.10

In this minor update we improved the rendering performance in the off-screen rendering mode for Swing, JavaFX, and SWT, restored functionality that allows disabling the internal Chromium traffic that was temporary dropped in 7.0, and improved stability of the library.

Rendering Performance

The off-screen rendering mode has been re-implemented to improve its rendering performance on all supported platforms and UI toolkits.

The results of the rendering performance testing on the different platforms on an HTML5 video in Frame Per Second ( FPS) are the following:

Windows

• Intel Core i7 7700k 4.2 GHz with GPU GTX 1070
• Video dimension: 1920x1080

Swing

JavaFX

SWT

macOS

• MacBook Pro 15”, Intel Core i7 2.9GHz with GPU Radeon Pro 650 4GB
• Video dimension: 2880x1800

Swing

JavaFX

SWT

Linux

• AMD FX-8300 3.3 GHz with GPU Radeon RX 480
• Video dimension: 1920x1080

Swing

JavaFX

SWT

For SWT UI toolkit on Linux we have not performed any optimization in the off-screen rendering mode yet.

Chromium Traffic

Chromium features such as Google Cloud Messaging, Translate Ranker, Extensions Updater, Safe Browsing, SpellChecker, Widevine etc. make requests to the external Google web services such as https://ssl.gstatic.com, https://clients4.google.com, etc.

When the web services are not accessible or you do not want this additional traffic, you can use the following API:

Engine engine = Engine.newInstance(
        EngineOptions.newBuilder(renderingMode)
                .disableChromiumTraffic()
                .build());

This option allows disabling only the Chromium features that are not accessible through JxBrowser API. For example, the SpellChecker and Widevine features can be accessible through JxBrowser API, so the option doesn’t disable the traffic caused by these features.

Focused DOM Element

The DOM API has been extended with the Document.focusedElement() method that allows obtaining the currently focused HTML element on the web page:

document.focusedElement().ifPresent(element -> {
    ...
});

Improvements

• Spell checking functionality has been restored.
• The com.teamdev.jxbrowser.view.swt.callback.DefaultStartDownloadCallback implementation now prompts when the target file exists and will be overridden.
• The DevTools.remoteDebuggingUrl() method now returns URL that can be used without Internet connection.

IPC Message Order

In the previous versions the IPC message order might be changed when a synchronous callback is invoked. For example, dispatching the keyboard events through the Browser.dispatch() method might lead to an issue with the randomly mixed letters in a text field on a web page.

Explanation: when a synchronous callback is invoked, we start a nested loop processing incoming messages. The problem is that there is a window between we get into the method invoking the callback and the moment when we actually start the nested loop. As the result, we can get a situation when some of the incoming messages are posted to the Chromium thread queue and those messages will be processed after the method returns. At the same time, those messages that arrive when the nested loop is started will be processed before the method returns, and this changes the order in which the messages were sent.

In this version we improved the internal IPC logic to get rid of such situations. This improvement introduces one important requirement on how you should process the code inside a synchronous callback. If you execute some logic that makes synchronous calls to the library in a separate thread inside a synchronous callback and blocks the callback awaiting until the logic has been executed, you might get a deadlock:

// Register a synchronous callback.
browser.set(SomeSyncCallback.class, params -> {
    // Invoke some logic in a separate thread and block the current
    // thread execution until the logic has been executed.
    invokeInSeparateThreadAndWait(() -> {
        // Invoke a synchronous method.
        browser.someSyncMethod(); // <-- Deadlock: this method will never return.
    });
    return Response.proceed();
});

To get rid of the deadlock, use the following approach instead:

// Register a synchronous callback.
browser.set(SomeSyncCallback.class, params -> {
    // Invoke a synchronous method.
    browser.someSyncMethod();
    return Response.proceed();
});

Fixed issues

• Unexpected content scaling when resizing BrowserView in the hardware accelerated rendering mode on macOS.
• The NavigationException: Failed to load resource: ABORTED error on subsequent Navigation.loadUrlAndWait() calls.
• Mouse stuck on panning when exiting from and returning to BrowserView in the hardware accelerated rendering mode on Windows.
• JavaFX BrowserView not shown after hiding Stage in the off-screen rendering mode.
• Crash or freeze when closing Engine.
• Crash when displaying BrowserView in the hardware accelerated rendering mode on Windows.
• The library getting frequently stuck at IpcLibrary.sendData().
• The Swing, JavaFX, and SWT UI toolkit classes being located in jxbrowser.jar when they must be in separate JARs.
• The focus restoring functionality not working properly in SWT BrowserView.
• The Node.xPath() method generating incorrect Node indexes.
• The Engine initialization stuck at calling the ldd command to check the missing system libraries on Linux.
• Deadlock on accessing non-empty cookie store.
• The Chromium welcome page on Windows Server 2012.
• The incorrect order when dispatching keyboard events using the Browser.dispatch() method.

Download JxBrowser 7.10

请提供您的电子邮箱地址，我们会尽快将下载说明发送给您。

很抱歉，我们无法成功发送消息。请再次检查您的电子邮件地址是否正确无误。

提交

点击提交，即表示您同意 条款与条件.

发送...

请检查您的收件箱。

我们无法发送电子邮件。请使用直接链接下载JxBrowser。

如果您已经是我们的注册客户，您无需任何操作，即可轻松享受此次更新。

如果您希望深入了解并体验我们的产品，您可以申请评估许可证。

获取免费 30 天体验