On 6/2/2010 5:02 AM, Juan Vuletich wrote:
> Andreas Raab wrote:
>> Can you say something about what you're doing? I'm curious about what
>> you've done to address this issue (and whether it's applicable to
>
> I can't say much right now. I hope you understand.

I'm not sure. Do you mean you haven't quite worked it out and it's just 
not clear to you how best to describe it, or do you mean to protect your 
IP and don't want to talk about it in public?

> What I can tell you
> is that it is a post processing done on the rendering of a group of
> polygons. So it fills naturally in my #exportAsPNG: method. It is not
> too expensive, it makes my export operation about 20% slower. So, it
> might be adapted to real-time drawing of the morphic desktop. The issue
> is that if it is done on a morph by morph basis (so that drawing of
> different morphs is independent as it is today), then it would avoid the
> defect if it occurs between polygons belonging in the same morph, but
> not on polygons belonging to different morphs.

Right. Obviously, one needs to compute the full adjacency graph and 
overlap of the polygons to address the problem. Which is one half of the 
problem. If the input is well-structured, like for example in Flash 
(which has all the 'internal' adjacency information for its shapes) it 
is quite possible (though still pretty expensive) to compute accurate 
coverage without introducing these artifacts.

I remember looking at this briefly when I wrote the Balloon engine but 
kind of gave up on it due to the other half, namely the issues of 
horizontal and multiple sub-pixel edges. Theoretically it should be 
possible to adjust a classic scan line algorithm to compute the proper 
coverage but it became too messy too quickly ;-)

In any case, let me know when you got something written up; I'm just 
really curious what you're doing.

Cheers,
   - Andreas