Closed Bug 1120562 Opened 10 years ago Closed 9 years ago

jwsolution.net/index.php/demo flash magenta visual artifacts before video plays (and logs error messages and assertion failures)

Categories

(Firefox Graveyard :: Shumway, defect)

x86
macOS
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INCOMPLETE

People

(Reporter: cpeterson, Unassigned)

References

Details

Attachments

(1 file)

STR: 1. Load http://jwsolution.net/index.php/demo 2. Shumway logs a bunch of error messages in the browser console (below). 3. Click the video player's PLAY button, the video displays visual artifacts (a magenta column) :( but then the video starts to play correctly! :) "__flash__callIn: jwAddEventListener" ShumwayStreamConverter.jsm:802:6 "__flash__callIn: jwGetPlaylistIndex" ShumwayStreamConverter.jsm:802:6 "__flash__callIn: jwGetPlaylist" ShumwayStreamConverter.jsm:802:6 "There was an error calling back an event handler" jwplayer.js:4:183 "__flash__eval: try {__flash__toXML(function(dat) { jwplayer("jwplayer1696332562").dispatchEvent("jwplayerPlaylistItem", dat); }(({index:0,type:"jwplayerPlaylistItem"})));} catch (e) {"<undefined/>";}" ShumwayStreamConverter.jsm:789:6 Error: assertion failed shumway.player.js:132:39 TypeError: this._file is null shumway.player.js:25442:6 "Session #3: loaded 722/722" viewerPlayer.js:126:14 "assertion failed" shumway.player.js:132:16 "Loading error encountered:" "Category not found" shumway.player.js:148:6 "Session #4: loading http://jwsolution.net/components/com_jwplayer/nothing?busted=35373" viewerPlayer.js:104:10 Error: assertion failed shumway.player.js:132:39 TypeError: this._file is null shumway.player.js:25442:6 "Session #4: loaded 722/722" viewerPlayer.js:126:14 "assertion failed" shumway.player.js:132:16 "Loading error encountered:" "Category not found" shumway.player.js:148:6 "somewhatImplemented: public flash.ui.Mouse::static show" shumway.player.js:148:6
Summary: jwsolution.net/index.php/demo logs error messages and shows magenta visual artifacts → jwsolution.net/index.php/demo flash magenta visual artifacts before video plays (and logs error messages and assertion failures)
Blocks: shumway-jw1
So, I made the default color fill for surfaces debug mode-only in https://github.com/mozilla/shumway/pull/2047. That, however, didn't fix this issue. This is related to stencil buffers, which somehow get painted far too large in some cases, and then somehow overlay the actual bitmap data. I don't know enough about this code to understand what's going on here, so delegating to mbx. Steps to reproduce: 1. Make the browser window very wide, but not tall, so the aspect ratio is somewhat extreme 2. Open players/jwplayer.flash.swf from the Dropbox in the inspector Expected result: the Firefox logo should be displayed in all its pixelated glory. Actual result: the left third of the logo is displayed, but ~ the right two-thirds are just a magenta-colored rectangle: http://i.imgur.com/sphwCFw.png I looked at the various canvases involved, and the temporary canvas into which the logo is drawn is extremely wide and and filled with magenta in the entire right-hand side. It'd be great if we could fix this before whitelisting anything, as the visual effect can be quite jarring, and I don't see why we'd have any guarantee of it not happening to users.
Flags: needinfo?(mbebenita)
The stencil color is used to construct a masking layer, probably to mask video layers. However, since we don't render Video to a canvas element, we're probably failing to do the actual masking, somehow leaving the masking color around.
Flags: needinfo?(mbebenita)
Nope, this is definitely related to the bitmap. When I put a breakpoint there and manually change the color to something with alpha in it (but just this once, so not in general), then the logo is drawn with that alpha value.
Flags: needinfo?(mbebenita)
Ok, I figured this out. The issue is that, in _renderWithMask, we allocate the content and mask in the same surface. Then, because we have disabled clipping in _renderToTemporarySurface, we overwrite the content with the mask if the mask is larger than its allocated region. This all also explains why it only happens if the stage is small: otherwise the two regions are too big to fit into one surface, so the issue doesn't happen. I worked around the issue by forcing allocation of the mask region to go into another surface. Obviously, that's not ideal, so we should get clipping working if at all possible.
Attachment #8560870 - Flags: feedback?(mbebenita)
Product: Firefox → Firefox Graveyard
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → INCOMPLETE
Attachment #8560870 - Flags: feedback?(mbebenita)
Flags: needinfo?(mbebenita)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: