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:
11289c0
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.