Keith, Starting to think more about the implementation today.
You mentioned starting with trapezoids and letting triangles fall out of that. But, degenerate trapezoids can only make triangles that have at least one horizontal segment. So, is the plan to render triangles by using two degenerate trapezoids? (It's and odd geometry where trapezoids are more elemental than triangles, but perhaps that's life in the land of the raster scan). I'm thinking the trapezoid implementation will be a dual, simultaneous bresenham. So, the triangle case would have to do the same thing, but switch to a different line on one end partially through -- which is basically the same as two trapezoids then, so maybe this makes sense. I've also been thinking about what the precise specification might look like. The non-negativity constraint still feels funny to me here as it seems that the important "coincident triangle alphas sum to 1" will not hold for arbitrary trapezoids, but only those for which the client is extra careful. This feels weak to me, and I'm wondering if we can't do better, (or perhaps you've already got something in mind?). The problematic intersection point can only occur within one pixel inside the trapezoid, so can we not afford some extra computational complexity there as a special case? I don't know. Anyway, I'll keep going ahead with a first-cut implementation as we discussed while thinking about these things in the back of my mind. -Carl _______________________________________________ Render mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/render
