[cairo] Where's the bottleneck in using glitz/cairo/librsvg?

[David Turner]

Hello Keith,

Keith Packard a écrit :
> Given the goal of getting to hardware accelerated rendering, I'm not
> sure how we manage that without tesselation; hardware accelerators
> generally like to deal with objects with a fixed number of vertices.
>
>   
You seem to assume that polygon/quad rendering is the only way to 
achieve accelerated rendering;
however it's possible to use anti-aliased horizontal span rendering, 
which can be implemented either
by the 2D and 3D parts of the hardware. The spans can be computed by the 
client with a standard
polygon rasterizer.

You could argue that the 3D harware is going to be faster than the 2D 
one, but you also have to
account the performance of the tessellator and the rasterizer into the 
mix. I think it's going to be
worthwhile to experiment with both approaches to see what ticks best on 
most people's
hardware.


> Providing an in-Cairo software rasterizer which doesn't tesselate might
> make a lot of sense though; our current architecture was dictated by the
> Render extension specification.
>
>   
I understand that; by the way, there is a thing that tickles me 
regarding the Render specification and
I would appreciate a lot if you could clarify it to me. As I understand it:

A - precise poly mode enforces super-sampling with a fixed, non-squared, 
grid
B - imprecise poly mode enforces abutting edges

My knowledge of graphics hardware is pretty limited, and I'm wondering 
is there currently is any card
that is capable of accelerating *any* of these two modes correctly and 
directly (i.e. without performing
the corresponding super-sampling in software within the X11 server)

I think (but correct me if I'm wrong) that OpenGL only enforces the 
abutting edges for 'sharp' polygons,
which is why many fasst and clever multi-sampling tricks like quincunx 
or QUADFLIP can be used to
render anti-aliased edges instead. Of course, these are completely 
incompatible with XRender's
expectations.

Another similar question is, does Glitz comply with all these 
constraints ? But I'll try to look at its code
to understand that myself.

What am I missing there ?
>
>> Another option would be to put the tessellation code within the X 
>> server, which would only be
>> used if accellerated quad rendering is available on the hardware. If 
>> not, a normal non-tessellating
>> rasterization algorithm would be used to generate alpha horizontal 
>> spans, with just as much quality
>> as the current code.
>>     
>
> I can't put the tesselator in the X server for several reasons; mostly
> that X requests are atomic, and tesselation is 'expensive' leaving us
> with inconsistent latency for other applications.
Good point. I didn't consider this angle, mainly because XRender 
implements radial and conical gradients
(which require one square root extraction or arc-tangent per pixel), 
which also have their own latencies.

>  Secondarily, the entire polygon "must" fit in a single X request, or at least in the X
> server memory all at once; I suspect many polygons drawn today are
> beyond the maximum request size supported in the X protocol. Plus, the
> instances of hardware incapable of accelerating primitive polygons will
> shrink over the coming years; designing a system for disappearing
> hardware seems inefficient to me.
>
>   
It's still possible to limit the size's request by limiting it to edges 
located within a given horizontal
band (y1 <= y <= y2), so this wouldn't be a problem.

Regarding the "shrinking hardware design" problem, I'll take something 
that works well on today's
current hardware over some vaporous promises in the future, thank you.

You also forget the embedded world where there are still lots of cheap 
graphics chipset to deal with,
which won't see a shading language before a loooong time.
>> Also, I don't know how Xara LX achieves its high-quality high-throughput 
>> results, but I would be
>> surprised if this involved any tessellation. Hope to see that code soon.
>>     
>
> As the Xara code is just software, to a great extent it "doesn't matter"
> to us. We must focus on the accelerated case, and design code across the
> library and X server which takes adavantage of these capabilities. Even
> Xara can't match the performance of glitz today.
>
>   
it really depends on what you do, you must take the whole rendering 
process as a whole instead of
of focusing on the pixel pushing aspects of it. As an example, Glitz 
will only win you 4 frames/second
in Dave Reveman's updated cairo-dock benchmark, because Cairo's 
stroking/tessellation takes sooo
long compared to the rendering.

If the Xara code has an improved stroker and doesn't use tessellation, 
with comparable quality, I could
imagine that it'd beat Glitz in this specific benchmark.

In other words, the game is not necessarily over, and it's important to 
exercise any option we can in Cairo.
It doesn't matter to you, but it does to me, and the good thing is that 
we're able to both work without
stepping on each other's toes. Which is why I love open-source :-)

Regards,

- David Turner
- The FreeType Project  (www.freetype.org)


***********************************************************************************
Information contained in this email message is confidential and may be privileged, and is intended only for use of the individual or entity named above. If the reader of this message is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the postmaster at nds.com and destroy the original message.
***********************************************************************************