Shape Rendering

[mbebenita]

Tracking bug for correct shape rendering.

[mbebenita]

• [x] We seem to be filling shapes twice if they have strokes. I think the fill path is constructed twice, so if we use even-odd fill rules then we end up with no fill at all. /cc @tschneidereit. Example image below.

[mbebenita]

• [x] Santa.swf has a fill0 of 16320

applySegmentToStyles (shape.js:68)
convertRecordsToShapeData (shape.js:118)
defineShape (shape.js:379)
defineSymbol (resourceLoader.js:58)
onprogress (resourceLoader.js:183)
readTags (parser.js:65)
BodyParser.push (parser.js:309)
CompressedPipe.push (parser.js:231)
parseSWF (parser.js:394)
pipe.push (parser.js:347)
(anonymous function) (resourceLoader.js:390)
ResourceLoader.listener (resourceLoader.js:355)
ResourceLoader.postMessage (resourceLoader.js:350)
Loader._load.session.onprogress (Loader.js:481)
(anonymous function) (inspector.js:310)
BinaryFileReader.readAsync.xhr.onreadystatechange (binaryFileReader.js:80)

[mbebenita]

• [x] mush.swf: shape 82

I think this is a bitmap fill and looks like the fill is not transformed correctly.

[tschneidereit]

I think this is a bitmap fill and looks like the fill is not transformed correctly.

Yeah, we're not yet doing bitmap fill transforms correctly.

[mbebenita]

Yeah, we're not yet doing bitmap fill transforms correctly.

Similar thing at shape 931:

while the actual bitmap is okay: (930)

[mbebenita]

• [x] Filling twice when stroking (fail/strokes.swf) ignore the background color.

expected:

actual:

[mbebenita]

• [x] In the GL backend (fail/max-strokes.swf) looks like this:

I'm guess this is due to the stroke bounds not being computed correctly.

[mbebenita]

• [x] Various strokes - (fail/various-strokes.swf)

Expected:

Actual:

The green edge is a lot ticker, it seems like this happens if the width < 1, here it's set to 0.5. Also the bounds don't seem to be computed correctly.

[mbebenita]

• [x] Focal point uint8 or fixed8? see (http://logs.glob.uno/?c=mozilla%23shumway&s=6+Jun+2014&e=9+Jun+2014#c61868) (fail/king.swf)

[tbtlr]

• [ ] Support morphing.

[tschneidereit]

Support morphing.

Yes. My thinking on this has evolved a bit: I don't any longer think it's useful to write the morph-end coordinates into the same buffer as the morph-start ones. If we store them in their own buffer, we can keep that on the symbol and make the Graphics instance completely oblivious to the fact that there might be a morph. Only the (de-)serializer and renderer need to know about it. Oh, and I guess the engine for bounds calculations. Not sure yet where best to plug that in.

[tschneidereit]

CanvasPattern#setTransform has landed in Nightly, so at least there and in Chrome bitmap fills now work properly.

[mbebenita]

Various transformed bitmap fills it think (fail/char-image.swf)

To save space (I think), the image is only the top left portion of the shape. The rest of the shape is composed of bitmap fills that are flipped along the x and y axis.

I took the shape apart in (fail/char-image-apart.swf) the .fla is also there.

Simplified use case @ fail/f.swf

[mbebenita]

• [ ] Transformed gradient fills. We also need CanvasGradient#setTransform to support transformed gradients acid-gradient.swf. I've filed a bug in bugzilla for this https://bugzilla.mozilla.org/show_bug.cgi?id=1025769.

[tschneidereit]

I'm guess this is due to the stroke bounds not being computed correctly.

This was caused by us reading fill and line bounds the wrong way around for embedded shapes. Fixed by 5b503f4.

[mbebenita]

Graphics objects don't seem to be updated correctly in these games:

• [ ] games/truck.swf
• [ ] games/box/main.swf
• [ ] games/box/demo.swf

They are all related, so fixing one will probably fix them all.

[mbebenita]

• [ ] shapes/fail/wav.swf

[mbebenita]

• [ ] arch~/0156952ba7912be556c7835c8060b7f881566f05c2b5acc47b3b719614a173c4.swf

Error parsing gradient.

[mbebenita]

• [ ] arch~/22b43a512201748ab1fa7b8685832e8d90224e84f52402dfe83bc3ce4d0dfba3.swf

Looks like the vertical line is too thick.