Edit GPU Acceleration: User:SOFTowaha

You do not have permission to edit this page, for the following reasons:

The action you have requested is limited to users in the group: Users.
You must confirm your email address before editing pages. Please set and validate your email address through your user preferences.

Warning: This page already exists, but it does not use this form.

Path Rasterization

Seems to be one of the hardest things to accelerate.

See Jeff's survey email and the followups in the thread: [1]

Additional information:

Qt accelerates polygon rasterization by choosing a point, drawing a fan of triangles from that point to each polygon edge, and using the stencil buffer to track winding count. Qt uses the stencil buffer for both even-odd and non-zero winding rules (for non-zero it uses GL_STENCIL_TEST_TWO_SIDE_EXT or glCullFace). These are only used for "non-high-quality" antialiasing. For high quality antialising they tessellate and render trapezoids. For medium quality antialiasing they use GL_MULTISAMPLE. Trapezoid and ellipse rasterization use fragment programs if available. They have specialized tessellation for lines, rectangles, ellipses and convex shapes.
ShivaVG uses the fan approach, but with only GL_MULTISAMPLE antialiasing.
Amarinth (closed source) apparently tessellates the polygon to triangles and then rasterizes them using GL with FSAA. Incurs tessellation overhead, but claims that if you can cache the tessellation (cached triangles can be reused with different transformations), it's faster than the Qt approach (which requires two passes).
Here's a Microsoft paper [2] that builds, for each pixel, a list of polygon edges that could intersect a ray starting in the pixel and heading right, and then runs a GPU program in each pixel to compute coverage (by sampling, IIRC).

The thing is, everything we want to draw, except for SVG <path>s (and excluding glyph rasterization, which for now let's assume we won't accelerate), has simple geometry and could be rasterized by GPU programs that calculate whether a sample is inside or outside the shape. This might be very efficient if we use a variable number of samples depending on whether an edge passes through the pixel, giving us fast one-pass rendering. Not sure how to do that with the cairo API though.

But SVG paths may well become important; maybe we need a Qt-style approach for those?

Summary:

Cancel