Hello Sandro, Monday, November 5, 2007, 8:40:14 AM, you wrote: >> This is not a valid example because E5 would need to have both fill >> sides set.
SS> Why ? It could be a red line into a green-filled square. Yes, but it's part of the same shape and divides a filled area. If the line would have no fill styles set then this would be inconsistent information since the renderer, when processing the fill, just sees a line that at it's right side has no fill -> hence, it would not continue filling the scanline. Or the line is part of a subshape, in which case it is not related to the shape (point test would need take care of subshapes too, of course). It's up to the SWF generator to provide correct information. I've attached a test case. Can you check the line properties? I can't make much out of listswf' output... >> SS> E2 --> >> SS> +---------------+ Q : query point >> SS> | | >> SS> | | >> SS> ^ | <-E5 | E5 : nearest edge, left fill (hole) >> SS> | | +----+ | E3 E1..E4 : edges with right fill >> SS> E1 | | | Q | | >> SS> | +----+ | V >> SS> +---------------+ >> SS> <-- E4 >> >> E5 would have it's right side fill style set and thus we get the >> correct result (that Q is in the filled area). SS> No it's a left fill. I was wrong calling it an "hole". SS> It's not an hole, just a red square inside a green square. In this case it has a fill style for both sides (one for the red fill and one for the green one). Remember that a shape (exactly: a subshape) always provides information to render everything in *one* pass - the renderer will *never* paint over one pixel again for one single subshape. In your example the renderer won't draw a green rectangle and then a red rectangle on top of it. Instead, when drawing the scanling of "Q" it would start with green pixels, switch to red pixels for the inside square, then switch back to green pixels until it reaches E3. The point test does pretty much the same, but much simplified and much more efficient (just search the nearest edge instead of sorting and stuff). SS> Ok, you're right, both examples are not valid topologies, in both SS> cases E5 should have both fill styles. SS> Now, if they do not, we'd need the normalization phase we were talking SS> about, or just let it fail. In that case the renderer would produce weird results (that most probably even differ from renderer to renderer), so we shouldn't care. SS> I guess we can think about it when we have a real-world example exposing SS> the need for normalization. So far applying the ray-crossing algorithm to SS> any path with fill info fixed bug #21498. Since it just counts the number of crossings, it should fail your first example (line inside a filled shape). I'll try to implement my algorithm soon so we can check if it is valid (at least it will be a fallback if we decide to go the renderer way). Udo
line-in-fill.swf
Description: application/shockwave-flash
_______________________________________________ Gnash-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnash-dev
