On Thu, 2002-04-18 at 02:44, Torgeir Veimo wrote: > Ben FrantzDale wrote: > > I now have wonderful subpixel fonts on my laptop. This is a very good > > thing. > > Did you get subpixel AA with mozilla as well? I thought I already answered this but it was marked as un-repliedto... Yes, I did. --Ben
Carl Worth contacted me last week about starting an implementation for the trapezoid primitive in the Render extension. He has a need for translucent triangles and decided to take a stab at getting something working. We've been cooresponding for a few days and have started refining the specification to try and come up with a workable implementation. As this refinement will affect the specification, I asked whether it would be OK to forward the related messages to this list so that others might have a chance to see what's up. Following this message, I'll post our discussion to date, then expect to see on-going discussion from that point. Keith Packard XFree86 Core Team Compaq Cambridge Research Lab
Around 19 o'clock on Apr 26, Carl Worth wrote: > Do you have any hints, suggestions I might look at to save me some > time as I start looking at implementing this? I don't have anything written down yet, but I recently discovered that the solution I'd come up with to draw precise trapezoids won't work unless we change the coordinate space from 24.8 to 16.16. If you really do have time, we should chat on the phone, I have a serious need for this work as well, and could use some help in finalizing the details. You might read my render paper from Usenix last summer (http://xfree86.org/ ~keithp/talks), that has some of the problems discussed. (XXX) XXX-XXXX Keith Packard XFree86 Core Team Compaq Cambridge Research Lab
On Apr 26, Keith Packard wrote: > I don't have anything written down yet, but I recently discovered that the > solution I'd come up with to draw precise trapezoids won't work unless we > change the coordinate space from 24.8 to 16.16. Sounds fair enough. Core X is already limited to 16 bits, no? So losing these 8 bits from the integer part shouldn't be too much of a problem I would think. > If you really do have time, we should chat on the phone, I have a serious > need for this work as well, and could use some help in finalizing the > details. I think I really might. Why don't I give you a call Monday. Let me know what time is good. Or, since you get up later, you can give me a call as soon as you're available if you'd like. XXX XXX-XXXX. > You might read my render paper from Usenix last summer (http://xfree86.org/ > ~keithp/talks), that has some of the problems discussed. OK, I'll take that home for some weekend reading, (I know I've looked at it before but I could use a refresher). Talk to you Monday, - -Carl(Continue reading)
On Apr 26, Keith Packard wrote: > Around 21 o'clock on Apr 26, Carl Worth wrote: > > > I think I really might. Why don't I give you a call Monday. Let me > > know what time is good. > > Today would be a lot easier; Monday I've got quite a few things going on, > I won't really be free until Wednesday... Sorry Keith, I left just after my last message. I read over the Usenix 2001 render paper last night. I think I'm clear about most of the issues you brought up there. Although it's obvious you've done some explorations of implementation possibilities that aren't explained in detail there. I'm looking forward to talking you about it some more. If you happen to have some time this morning I'm pretty free so you can call me at home if you'd like. XXX XXX-XXXX. Otherwise, we can try for Wednesday. - -Carl - -- Carl Worth(Continue reading)
I've got some nickle code that draws trapezoids now; it's painfully slow, but at least it seems to generate the right results. I think it will be useful in validating and debugging a "real" implementation. > load "poly.5c" > Draw::draw (t1) > Draw::draw (t2) Keith Packard XFree86 Core Team Compaq Cambridge Research Lab (ed - I elided the sample application, please find it in CVS at keithp.com (http://keithp.com has directions))
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.
(Continue reading)
Thanks Keith, Unfortunately, I lost all of yesterday to meetings and other nonsense. Hopefully, today will be much better. This should be quite helpful. Thanks, -Carl On May 1, Keith Packard wrote: > > I've got some nickle code that draws trapezoids now; it's painfully > slow, but at least it seems to generate the right results. I think it > will be useful in validating and debugging a "real" implementation. > > > load "poly.5c" > > Draw::draw (t1) > > Draw::draw (t2) > > Keith Packard XFree86 Core Team Compaq Cambridge Research Lab >
On May 1, Keith Packard wrote: > \| > A > |\ > | \ > | \ > | \ > +----+-----+ > | \ | > ====B======C===D==== > | \ | > | \ | > | \| > | E > | |\ > ====F==========G=H== > | | \ > +----------+ \ > > 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 is what had been thinking to do originally. Do you see any problem with this approach?(Continue reading)
Hi Keith,
Here's a trapezoid that tests X-major lines of both slopes. Your code
gets one right, one wrong:
Trap::trap t3 = Trap::new (1.5, 15.5,
Line::new (Point::new (10, 1),
Point::new (60, 31)),
Line::new (Point::new (80, 1),
Point::new (30, 31)));
Currently my code gets both of these wrong -- but in the same way at
least. 
-Carl
RSS Feed9 | |
|---|---|
53 | |
31 | |
52 | |
84 | |
46 | |
29 | |
50 | |
128 | |
52 | |
16 | |
4 |
