I fear the only way to keep the sub-pixel computation to 64 bits is to
snap some of the intermediate results to the sub-pixel grid. For example:
\|
A
|\
| \
| \
| \
+----+-----+
| \ |
====B======C===D====
| \ |
| \ |
| \|
| E
| |\
====F==========G=H==
| | \
+----------+ \
Here, the sub-pixel area is the irregular pentagon BCDFE. My nickle
code computes that as AFH - ABC - EGH, but computing AFH exactly requires
a lot of bits (like more than 128).
I'm open to suggestion, but all I can think of this evening is to "snap"
the intermediate coordinates to the 16.16 grid. That seems to rather
constrain the implementation, depending on which coordinates get snapped.
If we do need to do this, then I suggest snapping the coordinates as they
intersect the bounding area of the pixel -- snap C and E, not A and H.
This makes the area computation BDGF - CDE work in 64 bits.
Another possibility that just occured to me -- compute the weighted
average of the area of BCHF and BDFG -- compute both BCHF and BDGF to the
number of alpha bits in the destination then weight them appropriately.
-keith
_______________________________________________
Render mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/render
