293813 - Camino updates Java applets on every keystroke (too often)

Status: RESOLVED WORKSFORME

(Camino Graveyard :: Plug-ins, defect)

Description

[Steven Michaud [:smichaud] (Retired)]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.7) Gecko/20050415
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.8) Gecko/20050427 Camino/0.8.4

When using the OJI Plugin interface (at least), Camino triggers two
separate updates for every keystroke that occurs when the focus is in
a Java applet.  This can cause the applet to flash annoyingly on every
keystroke.

I'm not able to test any other kind of plugin, but I suspect that
Camino behaves this way for every kind of OJI plugin, and perhaps for
every kind of plugin altogether.

It's possible for plugins to work around this problem (by squelching
unnecessary updates).  But that shouldn't really be required.

I'm the author of the Java Embedding Plugin
(http://javaplugin.sourceforge.net/).  My current version (0.9.1)
contains a workaround for what I've been calling the Camino "spurious
updates" problem (i.e. it squelches the unnecessary updates, as best
it can).  And it can be configured to output information to the Java
Console that demonstrates what I'm reporting here.

To turn on this kind of debug tracing in the Java Embedding Plugin,
add the following "Java Runtime Parameter":

   -Djep.debug.updates=true

Then you'll see that for every keystroke (not including arrow keys),
Camino makes a call to nsIPluginInstance::SetWindow() and posts an
update event (calls PostEvent() with an "EventKind" of "updateEvt", or
somehow causes this to happen).

This doesn't happen with Firefox (1.0.3) or Mozilla (1.7.7).

I tested with Camino 0.8.4 and with the latest Camino nightly
(2005-05-10-14).



Reproducible: Always

Comment 1

[Mike Pinkerton (not reading bugmail)]

-> simon

Comment 2

[Simon Fraser [no longer active]]

Do you have a stack trace for the update?

Comment 3

[Steven Michaud [:smichaud] (Retired)]

Attachment: Stack trace at setWindow() just after key down

Comment 4

[Simon Fraser [no longer active]]

The stack is showing that we redrawing the plugin, which means that it got
invalidated on the keydown (is this expected?). It seems that the real issue
isthat we call SetWindow() every time we paint, though that's probably in there
to get RealPlayer to display correctly.

Comment 5

[Steven Michaud [:smichaud] (Retired)]

Attachment: Stack trace at updateEvt just after key down

Here they are.	I'm not sure how much good they'll do you -- they both
seem to be spawned by [NSWindow displayIfNeeded].  But if you follow
the instructions I've given, you can demonstrate for yourself that a
call to setWindow() and an updateEvt occur every time you press a key
while a text input field inside a Java applet has the focus.  (To say
"whenever an applet has the focus" seems, after all, to be
imprecise/incorrect.)

To get these (and to make sure I had the right ones), I altered the
source code of MRJPlugin.plugin and JavaEmbeddingPlugin.bundle in the
following way:	I inserted empty calls to setWindowBreak() and
updateEvtBreak() at the appropriate places in MRJContext.cp, and I
inserted an empty call to keyDownBreak() in a "handler" for
[NSApplication sendEvent], which I used poseAsClass to "hook".	That
way I could see that the extra setWindow() and updateEvt "events" did
take place just after a key down, and that I was generating traces for
the right ones.  (I used gdb, of course, to set breakpoints at those
"empty calls".)

Comment 6

[Steven Michaud [:smichaud] (Retired)]

> which means that it got invalidated on the keydown (is this
> expected?).

I certainly didn't expect it, and don't think it should be considered
correct (or normal) behavior.  It doesn't happen in Firefox or
Mozilla.

> It seems that the real issue is that we call SetWindow() every time
> we paint, though that's probably in there to get RealPlayer to
> display correctly.

Groan :-)  The Java Embedding Plugin has now been changed to deal with
this problem ... though I've already had one bug report about a
problem that might be due to how I implemented my workaround.  But if
RealPlayer needs this behavior, I can probably keep revising my
workaround until I get it right.

On the other hand, it'd be nice to get rid of some or all of my
(hackish) workaround, if it turns out that RealPlayer (or something
else) _doesn't_ really need this behavior.

Comment 7

[Steven Michaud [:smichaud] (Retired)]

> It seems that the real issue is that we call SetWindow() every time
> we paint

No.  A spurious updateEvt is just as harmful as a spurious call to
SetWindow():  An updateEvt can't tell you to update only part of an
object, so (if you decide to pay any attention to it) you've got to
update the whole thing.  Just like with SetWindow().  Yes, I suppose
just one of them is better than having both, but there's nothing to
choose between them, as far as I can tell.

Better still to have _no_ screen updates be tied to every keystroke.

Comment 8

[Simon Fraser [no longer active]]

So can we find out where the invalidate is coming from?

Comment 9

[Steven Michaud [:smichaud] (Retired)]

I have no idea myself.  And I'm not (currently) in a particularly good
position to find out:  I don't yet know much about the Camino-specific
code.  And since I've got a workaround for this problem (though it's a
bit creaky), and a lot of other JEP-related things on my plate, I'm
not likely to start playing the code-detective with Camino for a
while.

In a few months I may have time to get back to this issue.

In the meantime, though, maybe someone else can take a crack at it.
Maybe someone on the Mozilla.org Mac programmer team.  Maybe someone
whose initials are JA :-)

Comment 10

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

Sounds very similar to bug 184755.

Comment 11

[Steven Michaud [:smichaud] (Retired)]

It does seem to be related (thanks for pointing it out) ... but only
in a general way:  Bug 184755 isn't Camino-specific, and is about the
(apparently excessive) number of updates that occur while scrolling.
This bug is Camino-specific, and is about updates that occur on every
keystroke.

I tried scrolling the example given in bug 184755
(http://www.lohn1.de/lobn.htm), and it _is_ very slow with Java 1.3.1
(using either Apple's Java Applet.plugin or my MRJ Plugin JEP), but it
isn't so bad with Java 1.4.X or 1.5 (using my
JavaEmbeddingPlugin.bundle).  The reason must be that
JavaEmbeddingPlugin.bundle suspends screen updates while the browser
window is scrolling or changing size.

By the way, it's been in the MRJ Plugin that I've been implementing my
workaround for this bug (bug 293813), so it turns out I've also been
addressing some of Simon's issues (in bug 184755).

Comment 12

[Simon Fraser [no longer active]]

The patch from bug 298961 may have changed things here so that SetWindow is only
called when the clip rect changes.

Comment 13

[Steven Michaud [:smichaud] (Retired)]

Yes, the per-keystroke call to SetWindow is gone, and its disappearance does
coincide with the fix for bug 298961 (landed on the trunk on 2005-09-28, and
on the branch two days later).

The per-keystroke updateEvt is still there, though.

But this particular case of the (general) spurious updates problem is no
longer a problem for the Java Embedding Plugin -- my workarounds eliminate the
its effects on the JEP, and seem to be quite stable.

Comment 14

[Simon Fraser [no longer active]]

(In reply to comment #13)
> The per-keystroke updateEvt is still there, though.

Surely this is expected (as long as you are typing in a text field), since
inputting text will invalidate some region of the text field, so that the new
text gets redrawn?

Comment 15

[Steven Michaud [:smichaud] (Retired)]

Yes, but a plugin has no way of knowing that the update is for only part of
its display, so it has to assume that the whole display needs updating.  There
isn't any per-keystroke updateEvt in Firefox.  I think that's the correct
behavior.

(I actually tried getting an "update region" for the Carbon WindowRef in the
MRJ Plugin's handler for updateEvts -- but that only works in a Carbon event
handler, when you're handling a kEventWindowUpdate event.)

Comment 16

[Stuart Morgan]

What's the state of this in trunk? I would guess that this is either fixed, or should live in Cocoa Widgets now.

Comment 17

[Steven Michaud [:smichaud] (Retired)]

This now seems older than the dinosaurs :-)

There may still be underlying issues, but I'm not aware of any that
have any ill effect on the Java Embedding Plugin.

I'm marking this WFM.

If others still see similar issues, they should open new bugs.

Comment 18

[Steven Michaud [:smichaud] (Retired)]

> There may still be underlying issues, but I'm not aware of any that
> have any ill effect on the Java Embedding Plugin.

Trunk and branches.