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)
Tracking
(Not tracked)
RESOLVED
INCOMPLETE
People
(Reporter: cpeterson, Unassigned)
References
Details
Attachments
(1 file)
(deleted),
text/x-github-pull-request
|
Details |
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
Reporter | ||
Updated•10 years ago
|
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)
Updated•10 years ago
|
Blocks: shumway-jw1
Comment 1•10 years ago
|
||
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)
Comment 2•10 years ago
|
||
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)
Comment 3•10 years ago
|
||
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)
Comment 4•10 years ago
|
||
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)
Assignee | ||
Updated•9 years ago
|
Product: Firefox → Firefox Graveyard
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → INCOMPLETE
Updated•9 years ago
|
Attachment #8560870 -
Flags: feedback?(mbebenita)
Updated•9 years ago
|
Flags: needinfo?(mbebenita)
You need to log in
before you can comment on or make changes to this bug.
Description
•