gnash-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re[2]: [Gnash-dev] Re: point test


From: Udo Giacomozzi
Subject: Re[2]: [Gnash-dev] Re: point test
Date: Mon, 5 Nov 2007 10:31:25 +0100

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

Attachment: line-in-fill.swf
Description: application/shockwave-flash


reply via email to

[Prev in Thread] Current Thread [Next in Thread]