JDK-8043234 : [mac] Firefox: Applets sometimes not painted on the startup
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 7-pool,8-pool,9
  • Priority: P3
  • Status: Resolved
  • Resolution: Won't Fix
  • OS: os_x
  • Submitted: 2014-05-15
  • Updated: 2014-09-26
  • Resolved: 2014-09-26
Related Reports
Blocks :  
JDK-8021383 - [mac] When many applets on page not all of them are loaded
Relates :  
JDK-8041131 - [mac] Several applets on a single page in Firefox result in high CPU load
Relates :  
JDK-8014369 - [macosx] Intermittently only some components refresh
Description
Applet with the static content sometimes appears as frozen 'progress ring'.

the applet is successfully started, it's paint() method is executed and it then normally receives all the events, but if the applet content is static and no repaint happens any more we may see that frozen 'progress ring'.
If any repaint happens later the app7let becomes completely visible and functions normally. 

For more details see here: JDK-8021383
Comments
JDK-8041131: (high CPU load) with different temporary fixes to plugin and Firefox (which I've specially built on Mac) I've reduced the CPU usage to ~0% bu that unfortunately didn't help with the original problem, i.e. we still periodically have some applets which don't display on start up. We are not going to fix this bug (I'll reassign it back to devs) since that doesn't resolve the original customer problem. And loading 30+ applets is not the real customer use case. JDK-8043234: This is definitely the Mac problem. MacOS provides us with some private API (JavaRuntimeSupport/JRSRemoteLayer) which may make this problem more visible. Assuming that this is very rare case (Mac + Firefox + several applets on the page) and it has a simple workaround (see below) we have decided to close this issue. To workaround the problem and to make sure that the applet with static content will be finally painted on startup one may include to applet the code which periodically (e.g. once per second) call a repaint() for some reasonable amount of time from startup. Here is my code with which the problem is not reproducible: public class A extends JApplet { public void start() { new javax.swing.Timer(1000, new ActionListener() { int runSeconds = 60; public void actionPerformed(ActionEvent e) { repaint(); if (runSeconds-- == 0) { stop(); } } }).start(); } }
26-09-2014
I've finally reduced the CPU load to nearly 0% (by different workarounds in the JDK and custom Firefox build) but this didn't have any effect on the reproducibility of this issue.
01-09-2014
Here is the duplicate problem: JDK-8014369 It could also be reproducible on a standalone app (no applets/jnlp) but quite more rarely and with a larger number of CGLLayers on screen (more than 200). With Firefox applet this might be easier to reproduce due to effect of the JDK-8041131 bug. The high CPU load is produced mostly by the OGL rendering routines due to profiling and this may affect the frequency of missing drawInCGLContext() callbacks.
16-07-2014
The problem sometimes reproducible even if no JVM relaunch happens. I.e. in a single JVM some applets are successfully drawn but for others the final drawInGLContext() (where initial applet content is painted) is missed. BTW the fact that this is reproducible in FF only may be related to the bug JDK-8041131 due to which the CPU load for FF is much higher than for Safari
17-06-2014
// Calls to setNeedsDisplay can sometimes be ignored, especially if issued // rapidly (e.g, with vsync off). .... (https://chromium.googlesource.com/chromium/chromium/+/trunk/content/browser/renderer_host/compositing_iosurface_layer_mac.mm)
17-06-2014
Related Chromium discussion http://code.google.com/p/chromium/issues/detail?id=340133
17-06-2014
It appeared that CAOpenGLLayer.setNeedsDisplay() call starts to be ignored at some point for some applets, i.e. there is no subsequent drawInGContext() callback. But later it starts working again. This may be caused by high CPU load while a lot of applets are loaded.
17-06-2014