JDK-8041131 : [mac] Several applets on a single page in Firefox result in high CPU load
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 7u51,8u5,9
  • Priority: P3
  • Status: Resolved
  • Resolution: Won't Fix
  • OS: os_x
  • CPU: generic
  • Submitted: 2014-04-18
  • Updated: 2017-11-06
  • Resolved: 2017-11-06
Related Reports
Relates :  
JDK-8021383 - [mac] When many applets on page not all of them are loaded
Relates :  
JDK-8043234 - [mac] Firefox: Applets sometimes not painted on the startup
Description
For each applet MozillPlugin creates a Timer which polls windowLocation 60 times per second. When a number of applets (10-20) are loaded on a page the CPU load of the browser + plugin-process might be up to 50-70%. 
May be it makes sense to reduce the polling frequency depending on the number of applets, i.e. share those 60 times/sec for all applets to reduce the total load. 

The sample app could be run from: 
http://nemo.sg.oracle.com:8080/manyapplet/demo.html
http://anashaty.ru.oracle.com:8080/many (20 applets)
http://anashaty.ru.oracle.com:8080/many/5.html (5 applets)
http://anashaty.ru.oracle.com:8080/many/10.html (10 applets)
http://anashaty.ru.oracle.com:8080/many/15.html (15 applets)
Comments
Architectural issue in Mozilla, likely nothing we can do about it.
06-11-2017
Reassigning this since it isn't closely related to the customer problem.
26-09-2014
When eliminated (1) too frequent windowLocation updates and (2) set the InvalidatingCoreAnimation drawing model the plugin-process CPU consumption reduced to almost 0% and the main Firefox process to about 10% for 20 applets (instead of ~150%)
23-07-2014
The high CPU load on the side of the plugin-process includes 2 components: 1. as stated in issue details this is frequent windowLocation updates 2. In Firefox the CoreAnimation drawing model is implemented by continuously (50 times per sec) blitting the GLLayer onto the primary surface, since it has no information on when the Layer is updated by the plugin (Safari uses native CoreAnimation and avoids that problem) . Some info on that: http://stackoverflow.com/questions/11950061/how-do-i-write-an-mac-npapi-plugin-with-opengl, http://www.escapedthoughts.com/weblog/geek/P110308-mac-npapi-plugins.writeback The second problem could be fixed by moving to the more advanced InvalidatingCoreAnimation drawing model. This is the right direction since there is even a bug to deprecate the CoreAnimation model at all: https://bugzilla.mozilla.org/show_bug.cgi?id=693727
17-07-2014
Reproducible on 8u5 and latest promoted 9b12.
12-05-2014
this bug is reported against JDK7 only, so assigned to sustaining
06-05-2014
It seems I've mistaken: I increased the timer period to 10sec, but the same CPU load still remains.
22-04-2014
I wonder if the timer itself is necessary. At the least they should all share the same timer.
21-04-2014