JDK-8088416 : Slow and neverending rendering of page
  • Type: Bug
  • Component: javafx
  • Sub-Component: web
  • Affected Version: 7u6
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2012-05-17
  • Updated: 2018-09-05
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbdUnresolved
Related Reports
Blocks :  
JDK-8087938 - JFXPanel with simple animation consumes entire CPU core (see PERF-326)
Blocks :  
JDK-8120086 - Node clip animation consumes a lot of CPU time when running inside JFXPanel
Relates :  
JDK-8102203 - ES2RTTexture.readPixels allocates new byte buffer for each frame
Description
Using the JavaFX 2.2 build 8 WebView embedded in NetBeans on Mac OS X 10.7.3 and JDK 1.7.0 u4.

After opening the attached project in the embedded WebView, the browser displays the "Loading" progress wheel that tries to connect to a (non-existent) web service, processor load jumps to about 60% and stays at 60% forever. See also the attached NetBeans profiler snapshot.
Comments
Dev team requested removal of 222-candidate designation due to inability to fix for 2.2.2 by Sept 27, 2012 target date.
12-09-2012
These warnings appear to be caused by a bug in WebKit and the use of jQuery 1.6.x in the app. See http://stackoverflow.com/questions/7825448/webkit-issues-with-event-layerx-and-event-layery and https://bugs.webkit.org/show_bug.cgi?id=86264 . The problem should go away if you upgrade to a newer version of jQuery. The problem should automatically go away in JavaFX 8.0, thanks to WebKit bug being fixed mid May 2012. Given that Chrome had this problem for so long, and that upgrading jQuery should eliminate the warnings, it is unclear if the problem is important enough for fixing in 2.2.2. If you need the problem to be fixed in WebView in 2.2.2, please raise a separate issue. From the patch attached to the WebKit bug, it should not be too difficult to apply the fix to 2.2.2.
07-09-2012
Yes - we currently display this stream in an output window in NetBeans.
07-09-2012
And by the browser log you mean the stream of console messages received through WebView debugging interface?
07-09-2012
This was in the Sep 5 build from http://jfx.us.oracle.com/hudson/view/2.2.2/job/2.2.2/
07-09-2012
> When I tried to reproduce this in the latest build, I was getting many messages like this in the browser log: Latest build of 2.2.2 or 8.0?
07-09-2012
When I tried to reproduce this in the latest build, I was getting many messages like this in the browser log: event.layerX and event.layerY are broken and deprecated in WebKit. They will be removed from the engine in the near future. (15:17:18:284 | warning, javascript) Isn't that suspicious? Should the cause of these messages be fixed?
07-09-2012
There is now an issue under the Runtime component that captures the fact that a simple animation running inside JFXPanel consumes an entire core: RT-24278. I am therefore marking this issue as dependent on RT-24278.
16-08-2012
So given that the remaining problems are tracked as PERF-326, can this issue be closed now? Or is there anything else outstanding besides PERF-326?
08-08-2012
If and when PERF-326 is resolved, I would like to get back to this issue and verify if the problem really goes away in WebView. For that reason, personally, I would like to keep this issue open for now.
08-08-2012
It turns out even trivial JavaFX animation consumes a lot of CPU time when running inside JFXPanel, see PERF-326.
13-06-2012
I could not get to all root causes, but I was able to reproduce the problem with only basic JavaFX shapes, that is, without WebView. The problem appears to have to do with non-rectangular clips that WebKit asks WebView to apply many times when rendering pages like this. Filed a separate issue for this to hopefully get some feedback from the Graphics team: RT-21810
25-05-2012
On my quad core Windows laptop, profiling a simple example running a WebView inside a JFXPanel shows that the quantum renderer thread does indeed consume almost 100% of a core. This matches the 25% overall CPU consumption reported above. Profiler also shows that roughly 25% of that time is consumed by the EmbeddedPainter's call to D3DRTTexture.readPixels(), while the rest is consumed by NGWebView.renderContent(). If I comment the call to D3DRTTexture.readPixels(), the CPU consumption drops from 25% to 17-18% according to the task manager. So it looks like the problem is only partially caused by the issue uncovered in PERF-311, that is, D3DRTTexture.readPixels() is not the only thing that works slower when WebView is embedded into JFXPanel.
24-05-2012
On a Mac I have at hand, the situation is a little better. As I switch from normal WebView to WebView embedded into JFXPanel, the CPU time consumption goes from 20% to about %80.
24-05-2012
> Could this be related to bug PERF-311? I have tried opening the attached page in both a WebView running inside a normal JavaFX scene and a WebView running inside a JFXPanel. Once the page is loaded, the former starts consuming about 5% of CPU time whereas the latter starts consuming around 25% of CPU time. So I can confirm that WebView running inside JFXPanel has performance problems. I have four cores so the numbers looks consistent with what you are seeing. This does look like a variation of PERF-311. However, I am observing this on Windows so this may end up having a different root cause than the one mentioned in PERF-311.
24-05-2012
> The top four CPU time threads ... each consume 100% of a CPU core. Is that expected? This number is incorrect, because they all end in a native method, which is always displayed as time spent in a CPU, but in reality that's not true. Also in the Mac OS X Activity Monitor, the overall CPU usage by NetBeans is around 50%. > QuantumRenderer-0, on the other hand, consumes only around 50% of a core. Is this what you are seeing? How many cores does you machine have? Yes, that's what I am seeing. The machine has 2 cores (2.4 GHz Core 2 Duo processor). > Also, I see the application prints a lot of exception stack traces. What are those exceptions? I don't have the log any more, but I think they are those reported in bug RT-21410. > As a side note, since WebView is expected to continue showing the spinning wheel, it is expected that JavaFX is doing something, > just because it needs to continue rendering the wheel changes. I see, you are right. But I would expect this to take much less than 50% of a processor core. Could this be related to bug PERF-311?
23-05-2012
The top four CPU time threads, Thread-3, Thread-4, and org.netbeans.modules.glassfish.common.LogViewMgr* ones, each consume 100% of a CPU core. Is that expected? QuantumRenderer-0, on the other hand, consumes only around 50% of a core. Is this what you are seeing? How many cores does you machine have? Also, I see the application prints a lot of exception stack traces. What are those exceptions? As a side note, since WebView is expected to continue showing the spinning wheel, it is expected that JavaFX is doing something, just because it needs to continue rendering the wheel changes.
23-05-2012
The spinning wheel that says "loading" is expected - no problem with that. But in WebView, even after the page was rendered, the processor was still at 60% usage forever and JavaFX was doing something, see the attached profiler snapshot (you can open the file using NetBeans). Especially the QuantumRenderer-0 thread looks suspicious in the snapshot.
22-05-2012
What exactly is wrong with this scenario? I get the same behavior with Safari.
22-05-2012