[prev in list] [next in list] [prev in thread] [next in thread] 

List:       xfree-render
Subject:    Re: [Render] Point sampling trapezoid alpha (was: Another subtle issue...)
From:       Vadim Plessky <lucy-ples () mtu-net ! ru>
Date:       2002-12-19 18:32:44
[Download RAW message or body]

On Thursday 19 December 2002 20:09, Carl Worth wrote:
|  On Dec 14, Keith Packard wrote:
|   > I was chatting with Lyle Ramshaw on Thursday and he suggested that we
|   > reappraise our alpha computation technique.  Switching from area
|   > computation to point sampling would eliminate the difficulties we're
|   > having with negative alphas and weird interactions of multiple edges
|   > within the same pixel.
|   >
|   > The basic idea is to place points within the pixel and count how many
|   > are "inside" the trapezoid.
|
|  This looks like a promising approach. I'd like to pick up where Keith
|  left off as far as formalizing the description above.
|
|  Keith already proposed a formula for the number of sample points per
|  pixel as well as a rectangular grid relationship among the points:
|
|  	d == alpha depth
|  	s == # of sample points per pixel
|  	w,h == width and height of rectangular grid (w * h = s)
|

Hello Carl,

I am wondering: do you assume 	that d (alpha depth) is integer?
IIRC, alpha is float in Xr.

Xr:  xrint.h
--------------------------------------
typedef struct _XrColor {
    double red;
    double green;
    double blue;
    double alpha;

    XcColor xc_color;
} XrColor;

I am also wondering how your algorithm would work with 1x1 rectangles 
("trapezoids"), and other small in size trapezoids (1x2, 2x2, 2x2).
Do you plan to have some kind of exceptions for those sizes?

|  	     d
|  	s = 2  - 1
|
|  	               (d/2)
|  	w = { d even: 2      + 1 }
|  	               d
|  	    { d  odd: 2  - 1     }
|
|  	               (d/2)
|  	h = { d even: 2      - 1 }
|
|  	    { d  odd: 1          }
|
|  The next question is how to place these points on Render's subpixel
|  grid. I propose that the first point should be placed on the integer
|  coordinate of the whole-pixel grid.

Do you make some assumptions of sub-pixel geometry here, or that *geometry* 
can be *tuned*, in some way, in the future?
While we have 1x3 sub-pixel geometry for LCD panels today, there is no 
warranty that sub-pixel geometry would remain unchanged in the future.

|
|  So, given a pixel with integer coordinates (pixel.x, pixel.y), the
|  ideal coordinates of the sample point p[i,j] (0<=i<w, 0<=j<h) are
|  given by:
|
|  	p[i,j].x = (pixel.x << 16) + i * (1<<16) / w;
|  	p[i,j].y = (pixel.y << 16) + j * (1<<16) / h;
|
[...]
|
|  -Carl
|
|  _______________________________________________
|  Render mailing list
|  Render@XFree86.Org
|  http://XFree86.Org/mailman/listinfo/render

Cheers,
-- 

Vadim Plessky
SVG Icons * BlueSphere Icons 0.3.0 released
http://svgicons.sourceforge.net
My KDE page
http://kde2.newmail.ru  (English)
KDE mini-Themes
http://kde2.newmail.ru/themes/
_______________________________________________
Render mailing list
Render@XFree86.Org
http://XFree86.Org/mailman/listinfo/render
[prev in list] [next in list] [prev in thread] [next in thread]