SWFShape::export - conceptually wrong?

[timknip]

Hi Claus,

I stumbled on a problem with SWFShape.export()

The problem being that "fills" are exported first and the "strokes" after that.

This gives z-sort problems between fill / stroke when the shape for example contains multiple overlapping filled and stroked rectangles. The current export seems to assume that a Shape contains only a single primitive.

Maybe better if DefaultShapeExporter would have a method like: beginStyle ( lineStyle, fillStyle ) beginPath() ... endPath() So exporters know both lineStyle and fillStyle for the current path? (just thinking aloud) => with benefit of not needing SWFShape::exportLinePath() ;-)

Maybe I'm missing something, if so ignore.

Regards, Tim

[claus]

Hey Tim, that's a valid thought. However, i've never encountered any SWF that has overlapping edges - at least not those produced by Adobe tools. Theoretically though, i think it is possible (the SWF spec doesn't explicitly forbid that). Have you ever tried to create a SWF that has overlapping edges? What does the Flash Player do with it?

[timknip]

Well, I assume the exporter works as it works now due to fillStyle0 / fillStyle1 (winding rules). To find clockwise / counter-clockwise paths. That in itself works perfect. Now the problem is that "stroke info" isn't passed into begin_fill(), so exporters don't know how to stroke the fill. Anyway: I think Flash player works as follows: 1] draw the shapes including stroke info (if the shape is stroked / has_line_style of course) 2] draw "empty" shapes, or in other words: "strokes only" Of course I might be mistaken.

Here's an example swf: https://dl-web.dropbox.com/get/Public/drumstel.swf?w=8368cbb9 Its a drumkit. Problem is with the bass-drum: there's a rectangle which left/right sides stroke "over" the bass-drum. This is not correct: the strokes should be "behind", ie: on the z-position of the rectangle shape.

[timknip]

Of course: this isn't a very common case. Users have to really force things for this issue to show (as Adobe Tools often take care of overlapping edges as you noted). However: if users persist they can create SWFs exposing the issue.

[timknip]

Here's a PNG showing the drumkit issue: https://dl-web.dropbox.com/get/Public/drumstel.png?w=9b8af18d => you see the base-drum's sides thru the 2 drums above it. => that 2 drums and the base-drum are defined within the same Shape

[claus]

Your Dropbox links don't work for me (?)

[timknip]

hmmm, weird. https://github.com/timknip/as3swf/blob/master/data/ (sorry for this odd route :)

[timknip]

Anyway: I'll do some more research on this. Let you know later this week what I find.

Just feel it would be better if lineStyle and fillStyle are exported in the same loop: if lineStyle: handler.beginLine() if fillStyle: handler.beginFill() moveTo lineTo .... if fillStyle: handler.endFill() [repeat for remaining edge-records]

[timknip]

Hm. Did some reading (including your post http://wahlers.com.br/claus/blog/hacking-swf-1-shapes-in-flash/) It sure looks likely sorting of strokes goes by lineStyle. Lets forget for a moment non-Adobe tools like Ming et al. Also the strokes after fills looks like its correct (i'm backtracking :)

Imported "drumstel.swf" into Flash CS5 and observed the drum-kit shapes are grouped. After ungrouping and saving the SWF the export is correct!

Question of course: is it possible to detect this grouping? Flash player might work for a single shape like: startGroup() renderFills() renderStrokes() [some magic code] endGroup() startGroup() renderFills() renderStrokes() etc...

Quest continues....

[edit] actually: this theory seems nonsense :-) All I know that for some reason grouping seems related to the issue.

[claus]

Hmm interesting. How did you create the drumkit swf?

[timknip]

Unproved Theory: The main sorting is by fillStyle. After output of the current fillStyle directly output the strokes (in lineStyle order). Repeat for each fillStyle. Finally output edges having no fillStyle.

Investigating...

[timknip]

drumkit is for sure Adobe output.

[claus]

Oh i thought that was home grown. Ok, then this absolutely deserves investigating.

[timknip]

Interesting pattern while tracing out shape records of drum-kit swf :

[...] LINE_TO LINE_TO SELECTING LINESTYLE: 0 SELECTING FILLSTYLE_0: 0 SELECTING FILLSTYLE_1: 0 MOVE_TO SELECTING LINESTYLE: 2 SELECTING FILLSTYLE_1: 5 MOVE_TO LINE_TO LINE_TO

The reset of ls, fs0 and fs1 to zero might indicate "end of group".

[timknip]

This are subsequent records (note the state flags!): [...] [SWFShapeRecordStraightEdge] Horizontal: 36 [SWFShapeRecordStraightEdge] General: -4 1 [SWFShapeRecordStyleChange] moveTo: 0 0 fs0: 0 fs1: 0 linestyle: 0 state_flags: 1 1 1 [SWFShapeRecordStyleChange] moveTo: 946 -1127 fs0: 0 fs1: 8 linestyle: 5 state_flags: 0 1 1 [SWFShapeRecordStraightEdge] Horizontal: 16 [SWFShapeRecordStraightEdge] General: 13 8 [...]

Don't believe this is coincidence: maybe fills and strokes should be "flushed" at this point to keep z-order?

[claus]

You might be on to something there. I was wondering about subsequent moveTo's myself, as that doesn't make sense (i ignore those when exporting). Maybe it's there for a good reason after all..

[claus]

Tim, check this out: https://github.com/claus/as3swf/commit/11289c032ef6254ec3577a50f04627c39f7288ba http://codeazur.com.br/stuff/drumstel.png Looks better, eh?

[timknip]

Ha! Cool, thanks! I'll throw some more SWF at it to solidify the theory :-)

Will put a python-port on github (pyswf :) later this week or next week. Also will update my as3swf fork with a descent SWF=>SVG exporter (bitmap-fills, basic filters) asap. Closing the issue.