184755 - Scrolling pages with java applets is very slow

Status: RESOLVED WORKSFORME

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

Description

[Simon Fraser [no longer active]]

Scrolling pages with java applets is very slow. The reason is that on each
scroll, the applet redraws itself several times:
  SetWindow() calls in ScrollPositionDidChange, which were added for RealPlayer
  synchronous Invalidate() calls in ScrollPositionDidChange (not sure why
    this was added)
  and maybe a Paint().

Comment 1

[Simon Fraser [no longer active]]

Notes to self:
  nsPluginInstanceOwner::Paint calls SetWindow() to get RealPlayer to draw
     in the right place. Calling this also fixes a weird scrolling issue with
     the PDF plugin.

  nsPluginInstanceOwner::ScrollPositionDidChange also calls SetWindow to get
     RealPlayer to draw correctly.

  nsPluginInstanceOwner::ScrollPositionDidChange calls Invalidate(PR_TRUE) on
     the widget for some reason (scrolling with QuickTime?)

  The MRJ plugin code forces several redraws of the applet on scroll events:
     MRJPluginInstance::HandleEvent calls MRJPluginInstance::inspectInstance on
     every event, which calls MRJContext::inspectWindow, which does a 
     synchronizeClipping() if the scroll position changed, which in turn
     does a synchronizeVisibility().

     MRJContext::setWindow() calls synchronizeClipping()
     MRJContext::scrollingEnds() calls synchronizeClipping()

So we end up with 5 or 6 redraws of the applet per scroll event.

Comment 2

[S Woodside]

I can't find any of this code that is Camino-specific. where is it?

Comment 3

[Simon Fraser [no longer active]]

I don't think any of that is Camino-specific.

Comment 4

[Samuel Sidler (old account; do not CC)]

Ping. If this isn't Camino specific, can we resolve this bug as INVALID?

Comment 5

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

This bug probably is part of what Steven Michaud calls the "Mozilla family
spurious  updates problem" (which he's worked around to some extent in
JEP)...see also bug 293813 comment 11.

My guess is this belongs in Core: Plugins, not INVALID.

Comment 6

[Simon Fraser [no longer active]]

-> Core

Comment 7

[Steven Michaud [:smichaud] (Retired)]

> My guess is this belongs in Core: Plugins, not INVALID.

> -> Core

I agree.

Scroll this page in Safari with Java 1.3.1 (temporarily drag
JavaPluginCocoa.bundle out of /Library/Internet Plug-Ins/).  Then try
it in Firefox or Camino using Java 1.3.1 via the MRJ Plugin JEP (drag
JavaEmbeddingPlugin.bundle temporarily out of /Library/Internet
Plug-Ins but leave MRJPlugin.plugin in place).  There's a _big_
difference (Firefox and Camino scroll much more slowly).  The
performance is less bad if you also drag out MRJPlugin.plugin (so that
Firefox and Camino so Java 1.3.1 via Apple's Java Applet.plugin), but
still not as good as Safari.

The difference between scrolling in Java 1.3.1 via Java Applet.plugin
(a Netscape-4-style plugin) and via the MRJ Plugin JEP (an XPCOM
plugin) seems to be that, in the latter case, two additional kinds of
event are sent (ScrollingBeginsEvent and ScrollingEndsEvent) ... _far_
too often (sometimes several pairs per second).

You can see this for yourselves (in the Java Console) if you add
"-Djep.debug.updates=true" (without the quotes) to the Java Console's
Java Runtime Parameters box.  For this you need to be running Java
1.4.X (or 1.5) -- the logging capability is in
JavaEmbeddingPlugin.bundle.  But Firefox and Camino can't tell which
Java version they're using, so they behave the same way regardless.

Comment 8

[Steven Michaud [:smichaud] (Retired)]

Something I forgot go mention:

This bug's URL scrolls quickly when using Java 1.4.X or Java 1.5 --
despite all the excess ScrollingBegins and ScrollingEnds events coming
in to the MRJ Plugin JEP (and its resulting excess calls to
MRJContext::synchronizeClipping()).  The reason is that
JavaEmbeddingPlugin.bundle suspends screen updates from the JVM to an
applet's display area around every change in that applet's location or
clipping.

Comment 9

[Steven Michaud [:smichaud] (Retired)]

More detail:

> The reason is that JavaEmbeddingPlugin.bundle suspends screen
> updates from the JVM to an applet's display area around every change
> in that applet's location or clipping.

The JavaEmbeddingPlugin.bundle also (via the MRJ Plugin JEP) increases
the (per applet) "suspend updates count" with every
ScrollingBeginsEvent (for all applets in a given page) and decreases
it with every ScrollingEndsEvent.  JVM screen updates are off (for a
given applet) while the count is above zero.

Comment 10

[Wayne Mery (:wsmwk)]

smichaud, is this still seen with current versions of java on Mac? If so, there's probably a better component for this now?

Comment 11

[Steven Michaud [:smichaud] (Retired)]

> smichaud, is this still seen with current versions of java on Mac?

No, not as far as I can see.  I think we can just close this WORKSFORME, as per comment #8 and comment #9.