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 :  
Relates :  
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://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)

Architectural issue in Mozilla, likely nothing we can do about it.

Reassigning this since it isn't closely related to the customer problem.

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%)

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

Reproducible on 8u5 and latest promoted 9b12.

this bug is reported against JDK7 only, so assigned to sustaining

It seems I've mistaken: I increased the timer period to 10sec, but the same CPU load still remains.

I wonder if the timer itself is necessary. At the least they should all share the same timer.