Around 21 o'clock on May 2, Raph Levien wrote:
> Wow, it looks complicated. Yes, the requirement that an arbitrary tesselation always exactly fill a pixel was somewhat difficult to get my head around. I believe that an implementation will be significantly shorter than my previous mail message; it's not all that complicated in practice. The basic idea is to balance errors automatically by computing b = (ab) - a instead of attempting to separately compute a and b and then ensure that ab = a + b. As can be seen in the previous message, the area covered within a single pixel by any one trapezoid takes only a couple of short computations. I'm hoping to get Carl to build a sample in the next day or so. That will give us an idea of how big an eventual (performant) implementation will be. > While you're brainstorming, you might want to look at the way Libart > does its exact area computation. There are a few observations there > that might be useful. I think it's quite similar in the higher level; I believe I can convert from SVP to trapezoids and back without loss of precision (aside from the conversion from float to fixed numbers). One important feature of using separate trapezoids rather than SVP sets is that I needn't have the whole complex figure present to rasterize it; each trapezoid is rasterized separately. The final result always turns out correct because of the tesselation properties I attempted to show. X requests need to be short; they represent the scheduling quanta as they are executed to completion before any other activity can occur. While applications can send long lists of trapezoids to the X server, the effect is defined to be equal to sending each trapezoid in a separate request, allowing applications (or, more likely, the toolkit or library) to balance performance vs latency. The SVP algorithms are also a bit numerically "messy" for the insides of the X server; the use of floating point makes the output vary under translation as well as depend on the precise floating point implementation. I like the notion of a pure fixed-point 'bresenham' implementation that requires few multiplies and divides -- it will not generate any performance problem on my iPAQ, and will generate precisely the same result on every machine. I agree that an important metric of the standard will be the size of a minimal conformant implementation -- the experience of the core X primitives have left me very cautious; requiring thousands of lines of code just to draw axis-aligned ellipses should be taken as a resounding vote of no-confidence in the original specification. Let's see how the implementation proceeds and weight the results in the balance. Keith Packard XFree86 Core Team Compaq Cambridge Research Lab _______________________________________________ Render mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/render
