137559 - OS X: Mozilla gives fewer nullEvents than expected to plugin

Status: RESOLVED INVALID

(Core Graveyard :: Plug-ins, defect, P2)

Description

[Michelle Sintov]

From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0b; Windows NT 5.0)
BuildID:    20011022

Netscape 6.2 on OS X gives a plugin fewer nullEvents than expected.  The Flash 
Plugin currently does not fully use Carbon Events, and thus relies on 
nullEvents for processing time.  This setup works for Classic Netscape browsers 
(including 4.* and 6.2, though we do see a slight decrease in nullEvents in the 
Classic 6.2 build), but for OS X Netscape 6.2, the number of nullEvents 
received drops significantly.  As a comparison, OS X NS 6.2 hands off 25% of 
the nullEvents that OS X IE 5.1 does.

Reproducible: Always
Steps to Reproduce:
1. Create a plugin that does nothing other than count the number of nullEvents 
received, by putting a global counter in npshell.cpp and incrementing it when 
NPP_HandleEvent receives a nullEvent.
2. Install this plugin.
3. Run the browser.
4. Navigate to content that uses this plugin.
5. Observe the event counter and compare to other browsers.

Actual Results:  The number of nullEvents received by the plugin on OS X NS 6.2 
is far fewer than on Classic NS 4.* or 6.2, or OSX IE 5.1.

Expected Results:  More idle time should be provided to the plugin via 
nullEvents.

Comment 1

[Greg K.]

Michelle, can you reproduce this problem using a Mozilla (rather than Netscape)
build?

Comment 2

[Peter Lubczynski]

Michelle,
Do you find the same is true with recent Mozilla nightly builds:
http://ftp.mozilla.org/pub/mozilla/nightly/latest/

I wonder if the timer is not going off enough or its being starved?

Comment 3

[Peter Lubczynski]

Confirming this is still happening with a testcase Michelle sent.

I think maybe a tester plugin may be needed here to more accuratly measure the
rate of nullevents sent to IE, 4.x, and Opera and compare to us.

Comment 4

[Brian Nesse (gone)]

4.x sent null events, from the main event loop, whenever the program was idle.
This basically sent messages as fast as possible when nothing else was
happening. We are now sending these messages at a fixed interval... when we send
them too fast we kill the cpu and/or block other timer processing, when we send
them to slowly macromedia complains. ;)

Other timer related bugs I'm aware of are bug 111982 and bug 123273. Although
these are related to the SetTimeout() timer, the problem remains the same... too
many timer callbacks kills the system, too few appears to be non-performant.

I think we really need to come up with a better model for giving time which is
dependent on the current cpu load rather than on fixed interval timers.

Comment 5

[Steve Dagley]

In the CarbonEvent world where RunApplicationEventLoop replaces WaitNextEvent
the concept of application idle time breaks down.  A periodic timer is the new
solution but, as Brian notes, the issue is what frequency to set for this timer.
 Since the needed/desired frequency varies from plugin to plugin perhaps it's
time to expand the plugin API to allow a plugin to specify the refresh rate it
needs/wants? 

Comment 6

[rubydoo123]

adding nsbeta1+

Comment 7

[rubydoo123]

moving to 1.3 beta

Comment 8

[Kevin McCluskey (gone)]

nsbeta1-. Peter is overloaded with higher priority issues.

Comment 9

[Philipp Ringli]

apple seems to have solved the flash plugin problem with their lates Safari release.
the speed greatly increased. still not as good as IE, but they are close. also opening 
multiple browser windows with cpu-intensive flash content won't bring safari down as it 
can Mozilla.

maybe you guys should have a chat? ;-)

environment: OS X 10.2.4

Comment 10

[Simon Fraser [no longer active]]

There's no reason Mac plugins have to be fed null events in a CFRunLoop world.
The plugins could just install Carbon timers, or do other CFRunLoop magic.

Michelle: is this still an issue?

Comment 11

[Michelle Sintov]

(In reply to comment #10)
> There's no reason Mac plugins have to be fed null events in a CFRunLoop world.
> The plugins could just install Carbon timers, or do other CFRunLoop magic.
> Michelle: is this still an issue?

Yes, this is still an issue. Do you think that if we used Carbon timers, the 
Flash Player would get more time and we wouldn't have timing problems with the 
browser? We are very interested in finding a solution so please feel free to 
email me offline: [e-mail].

Comment 12

[Wayne Mery (:wsmwk)]

Michelle, is this still unresolved?

Comment 13

[Josh Aas]

Plugins should not be relying on nullEvents and we aren't going to be providing further fixes for for the Carbon or classic event models unless they are critical.