Around 15 o'clock on Apr 29, Carl Worth wrote:
> 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). Yes, that's the plan. Note that traps are the primitive in PostScript, and that they match the Render spec (oddly). > 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. Yes, we can do a triangle implementation at some point that would be more efficient than two traps -- the horizontal boundary will currently require three memory references per pixel while a straight triangle implementation would require only stores. > 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. Yes, we can accept that the client must be careful in tesselating the figure to get the right answer. That will have to be spelled out in the spec. The alternatives (as you've seen) are far worse. > 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. 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. > 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. Ok. Let's get something working, then we can go back and look at doing it the exact way and see how much code that's going to entail. Keith Packard XFree86 Core Team Compaq Cambridge Research Lab _______________________________________________ Render mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/render
