603397 - artifacts while playing transparent embedded Flash video with nspluginwrapper

Status: RESOLVED INCOMPLETE

(Core Graveyard :: Plug-ins, defect)

Description

[juan becerra [:juanb]]

Mozilla/5.0 (X11; Linux x86_64; rv:2.0b8pre) Gecko/20101011 Firefox/4.0b8pre (with default config settings)

This Flash video shows artifacts while playing: http://gizmodo.com/5659576/watch-the-sikorsky-x2-breaking-the-worlds-helicopter-speed-record

It's using the Flash installation you can get from Ubuntu's Synaptic Package Manager. Version: Shockwave Flash 10.1 r85

If you double click on the video, so that it opens in a separate tab in youtube, it plays well with no artifacts.

Comment 1

[Marcia Knous [:marcia]]

I am not seeing the artifacts in the QA lab machine running Mozilla/5.0 (X11; Linux i686 on x86_64; rv:2.0b8pre) Gecko/20101009 Firefox/4.0b8pre with Shockwave Flash 10.1 r85.

Comment 2

[Joe Drew (not getting mail)]

Juan, can you still reliably reproduce this? If so, is this a regression? If so, can you find a regression range?

Not blocking until we know whether this is widespread.

Comment 3

[juan becerra [:juanb]]

I can reproduce reliably. Here's the regression range (9/21 - 9/22): http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=8528ce3f97ce&tochange=198709160138

Comment 4

[juan becerra [:juanb]]

It's a Ubuntu 10.10 installation on hardware, by the way.

Comment 5

[Jeff Muizelaar [:jrmuizel]]

This looks like it could be async plugin stuff

Comment 6

[Joe Drew (not getting mail)]

Let's blame the relevant folk, who are guilty until proven innocent!

Comment 7

[Benjamin Smedberg]

Oleg is on vacation. I can't reproduce with the latest Shockwave Flash 10.2 d161. Since we can't reproduce with the Adobe version, I don't think this blocks, although we should talk to the Ubuntu maintainers to see if they can get an updated version or know what might be different between their version and the standard version.

Comment 8

[Daniel Holbert [:dholbert]]

Just since no one else has chimed in saying they can reproduce, I thought I'd mention -- I can confirm this bug using the link from Comment 0. Like Juan, I have Shockwave Flash 10.1 r85 (from Ubuntu 10.10) (flashplugin-installer package version 10.1.85.3ubuntu1)
Mozilla/5.0 (X11; Linux x86_64; rv:2.0b8pre) Gecko/20101014 Firefox/4.0b8pre

Comment 9

[juan becerra [:juanb]]

The Ubuntu version is probably the same as the one you can get from Adobe.

I, too, cannot reproduce using the development version 10.2 d161, which you can get by using their package manager. It may just be a matter of how long do people using Linux have to wait before 10.2 comes out and available by default.

Comment 10

[Karl Tomlinson (:karlt)]

http://packages.ubuntu.com/maverick/flashplugin-installer dependencies suggest that nspluginwrapper is being used to run 32-bit plugins in 64-bit browsers.

I wonder what the "artifacts" look like.

Comment 11

[Karl Tomlinson (:karlt)]

Do the artifacts appear on this site?
http://www.communitymx.com/content/source/E5141/wmodetrans.htm

If so do they disappear when following the "View the opaque wmode" link?

Comment 12

[juan becerra [:juanb]]

They look like little gray squares, which sometimes appear as you mouse over the playback progress bar, and sometimes they look like big rectangles covering the bottom part of the video. I'll share a screencast from that machine by tomorrow morning.

Comment 13

[David Benjamin]

I believe this is because Firefox is not detecting the nspluginwrapper-wrapped Flash as Flash and thus does not apply QUIRK_FLASH_EXPOSE_COORD_TRANSLATION. The code in PluginInstanceChild.cpp uses mPluginIface->getvalue (NPP_GetValue) to request NPPVpluginDescriptionString instead of NP_GetValue. Is there any reason this quirk is queried in the PluginInstanceChild constructor? Seems it would make more sense in PluginModuleChild.

I have an nspluginwrapper-side workaround that works, but it may not be unreasonable to query properly in Firefox. Right now it's passing an unconstructed NPP (pdata is NULL) to NPP_GetValue which is kind of weird.

https://github.com/davidben/nspluginwrapper/commit/ed1ac280ec7551776e2ded87f326747a445f1297

(I'm in the process of attempting to un-orphan nspluginwrapper.)

Comment 14

[Karl Tomlinson (:karlt)]

Thanks for the analysis, David.  That definitely explains bug 629472.
And yes it should be NP_GetValue in PluginModuleChild.

I suspect this bug may actually be an issue where with transparent plugins we sometimes ask the plugin to draw twice, once on black and once on white, so we can calculate alpha values.  This goes wrong if the event loop is run between the paints as Flash Player can update the frame.  That's a bit hard to correct in nspluginwrapper, but this situation should be happening much less often than it once did during Firefox 4 betas.

Comment 15

[David Benjamin]

(Ah, sorry, I did not realize there were two bugs.)

Ow. Is this for all transparent windowless plugins? I can reproduce some rendering artifacts pretty reliably if I zoom in and out on http://www.communitymx.com/content/source/E5141/wmodetrans.htm.

Is this from the nspluginwrapper child's event loop drawing in between the two? I may actually be able to help with that. Recently I reworked the sync mechanism to deal with a similar bug where something triggered another NPP_SetWindow between Chromium's NPP_SetWindow/NPP_HandleEvent pair. Originally, when both the plugin and the wrapper requested an operation at the same time, nspluginwrapper /guaranteed/ that their NPAPI operations would interleave with each other. Now the two halves will not uncork each other until returning to the event loop instead of after one operation.

https://github.com/davidben/nspluginwrapper/commits/rework-sync

The change prevents that bug, but not this one. I presume this is because the offending event loop iteration talks only/first to X? (The sync stuff does not trigger until the first RPC calls.) I can make the plugin sync with the wrapper before/after every iteration, but that may be a bit much. Another thought is that, right now the plugin syncs with the wrapper when it needs to make a call, but not the other way around. If I rework it to sync in the other direction too, then, from the duration of the first draw request (NPP_HandleEvent?) to the end of that browser event loop iteration (or more accurately the next time glib events are pumped) the plugin will block and will not return to its event loop. Would that work or am I misunderstanding the problem?

Comment 16

[Karl Tomlinson (:karlt)]

(In reply to comment #15)
> (Ah, sorry, I did not realize there were two bugs.)
> 
> Ow. Is this for all transparent windowless plugins?

What I was describing would be only for transparent windowless plugins, but not all transparent windowless plugins.

> I can reproduce some
> rendering artifacts pretty reliably if I zoom in and out on
> http://www.communitymx.com/content/source/E5141/wmodetrans.htm.

I actually wouldn't have expected what I described to happen on that site, as we now try to provide a background when possible so the plugin need only draw once.  Perhaps it might happen briefly after a zoom.  I'm not sure.  You may or may not be seeing something else.

I would expect these artifacts to manifest as the rapidly changing parts of the animation or movie becoming more or less transparent than they should be.

> Is this from the nspluginwrapper child's event loop drawing in between the two?

That was my theory.

> If I rework it to sync in the other direction
> too, then, from the duration of the first draw request (NPP_HandleEvent?) to
> the end of that browser event loop iteration (or more accurately the next time
> glib events are pumped) the plugin will block and will not return to its event
> loop. Would that work or am I misunderstanding the problem?

I didn't really follow much of what you were describing before this, but yes, if, after an expose handleevent is received, the nspluginwrapper child does not resume the event loop until the parent resumes the event loop, that should resolve the issue.

Comment 17

[David Benjamin]

To follow up, I've released nspluginwrapper 1.3.2 which completely binds the two event loops together. (While one process is running, the other blocks until it returns to the event loop.) This should take care of any of redraw race conditions and several others; I don't see issues when zooming on that URL anymore. (There are still some artifacts, but I see them with 32-bit unwrapped Flash, so I guess that's a Firefox issue.)

Arch Linux and FreeBSD have packages, and Fedora has one in pending state. Hopefully others will follow suit.

Comment 18

[Matěj Cepl]

Yes, I can confirm that with nspluginwrapper-1.3.2-1.fc15 I can play both speed streams of Bitstream on http://live.twit.tv without any problems (400 kbps used to be very bad in the previous version).

Thank you