Hello Sandro,
Monday, November 5, 2007, 8:46:12 AM, you wrote:
>> Bad. So we would need to take care of the cap and join styles too. So,
>> one point for the renderer-based solution.
SS> This is an SWF8 thing right ?
Don't know exactly, but most probably introduced in the latest
versions, yes.
SS> Do you have an example in which gnash fails ?
No, but it will obviously fail because measuring the distance only
works for rounded lines, of course.
Rounded join (default):
#
#######
###########
###############
######## ########
######## ########
Miter join:
#
###
#####
#######
#### ####
#### ####
#### ####
Bevel join:
#####
#######
#### ####
#### ####
#### ####
Also, there are different caps:
Round (normal): Square: No cap:
### ####
##### ####
##### #### ####
##### #### ####
>> Ok, but what is effectively "normalizing"?
SS> Building valid topologies from invalid ones (if worth it).
Sorry, still don't get it :( Can you use simple words instead?
>> SS> The query point should be passed in "local" coordinates already,
>> SS> which is the same coordinate space as the edges.
>>
>> The query point is not the problem. The shape itself must be
>> transformed (rotation etc.) :)
SS> I don't get this, could you provide an example in which this is failing ?
SS> (as we currently don't apply transformations to the shapes, but only
SS> to the point).
Hmmmm, maybe you mean the query point itself is transformed so that it
is relative to the normal size and orientation of the shape? Ok, that
makes sense. Would be interesting to know if scaling makes any
difference since the shape might contain small parts which are
invisible at it's normal size but are relevant when the shape is
greatly magnified. From the renderer point of view this might be very
relevant (like missing detail when upscaling a bitmap).
Udo
_______________________________________________
Gnash-dev mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/gnash-dev
