On Apr 29, Keith Packard wrote: > You're talking about doubling (probably) the amount of code, and also > requiring a lot of additional testing to make sure it works right in every > case. I'm not willing to place that burden on every implmentation, > especially for a single pixel. I am willing to require that apps > tesselate carefully to get the right answer; they'll probably do that in > any case.
Uncle! The code is bad enough without solving for the intersection. I won't ask for that again. I've made some progress. Here's some stream of consciousness: I suppose that since we're talking about precise trapezoids here, I must maintain precision enough to compute pixel coverage within 1 part in 2**16, (assuming maximum of 16 bits of alpha)? I've got the code figured out for line walking I think. Bresenham never really applies since in one dimension I walk a full pixel while in the other I walk some number of partial pixels, (so a binary decision variable doesn't help). I think I can preserve full precision by using a 64-bit fixed-point slope, (or inverse slope to keep it within [0, 1.0]). The one case I still need to think about precision is in clipping the initial left/right lines to the top line before starting the iterative walking. Maybe I'll just have to use the same iterative walk to extend from the points I'm given until I hit the top line. I don't know if that makes any sense at all. Maybe some code to look at tomorrow. -Carl -- Carl Worth USC Information Sciences Institute [EMAIL PROTECTED] 3811 N. Fairfax Dr. #200, Arlington VA 22203 703-812-3725 _______________________________________________ Render mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/render
