[Glamor] [PATCH 1/2] Change the trapezoid render to use VBO

[He Junyan]

Thanks a lot.
I remember it, and (2n+1)*(2n-1) make me confused then I read the code.


> On Wed, 18 Jul 2012 16:44:32 +0800, He Junyan <junyan.he at linux.intel.com> wrote:
>> Hi Chris:
>>
>>
>>> On Tue, 17 Jul 2012 06:53:41 +0800, junyan.he at linux.intel.com wrote:
>>>> From: Junyan He <junyan.he at linux.intel.com>
>>>>
>>>>    Because some uniform variables need to be set for every
>>>>    trapezoid rendering, we can not use vbo to render multi
>>>>    trapezoids one time, which have performance big loss.
>>>>    We now add attributes which contain the same value to bypass
>>>>    the uniform variable problem. The uniform value for one
>>>>    trapezoid will be set to the same value to all the vertex
>>>>    of that trapezoid as an attribute, then in FS, it is still
>>>>    a constant.
>>>
>>> This still has the problem that it misrenders neighbouring trapezoids,
>>> which is not permitted even in the imprecise specification (and since it
>>> does not conform to the specification of precise rasterisation it should
>>> not be used there either). To get around the former issue with the
>>> current design you still need an intermediate accumulation buffer.
>>
>> I really encounter some problems when the trapezoids adjoin each other.
>> The EDGE area will get a wrong result. Now in glamor, it generates a
>> temp mask
>> which stores the result of all the trapezoids's alpha value. By setting
>> glBlendFunc(GL_ONE, GL_ONE), if one pixel belong to two adjacent trapezoids,
>> the alpha value will accumulate and cut to 1.0 . So I think the problem of
>> misrendering neighbouring trapezoids may not exist.
> 
> Right if you use a mask in that case, you will prevent the overdraw.
> 
>> About the specification of precise rasterisation problem, the standard
>> manner
>> will expand one pixel to n pixels, caculate how may expanded pixels are
>> completely
>> inside the trapezoid and get the result by insides/total. If alpha depth
>> is 8,
>> it should be expanded to 8*8 pixels and caculate whether the pixel is
>> inside the
>> trapezoid for each of these 64 pixels. I find the trapezoid code in
>> pixman is
>> a kind of approximation by iteration and have high performance. But for
>> shader
>> I do not find an efficient way to do this. So I use float to caculate
>> the area
>> inside the trapezoid, and get the result by (inside area)/(one pixel
>> total area).
>> The difference is that some area that belongs to not completely inside
>> pixel has
>> been caculated in, and that's why my result is always a little deeper
>> than the
>> pixman's result in color. Do you think that the difference is acceptable?
> 
> I think it acceptable for imprecise rendering (which has been cairo's
> default mode now for a few years and hopefully the other toolkits will
> catch on ;-)
> 
> However, the specification for precise mode is that we sample the
> trapezoid on the centre points of an 17x15 subpixel grid (for 8-bit
> alpha, generally (2*n+1)x(2*n-1) for n-bit). The rationale for
> preserving is that it does produce very well defined results for any set
> of trapezoids, albeit at a slight cost of sample noise. Unfortunately it
> turns out to be computationally expensive...
> 
> Just treat Precise rendering as a fallback to a pixman trapezoid mask
> for now and focus on making Imprecise fast, and lets focus on making the
> next iteration of Render more amenable for GPU offload.
> -Chris
>