[Translation] scanline containers of spatial reference

Introduction

(Note: This reference does not seem to have been written, so the following is a translation of the officially released part)

Link: http://www.antigrain.com/doc/scanlines/scanlines.agdoc.html

Translation: Tang Feng

Underlying render operations are the simplest data forms, and of course they are also very simple. In fact, pixel format Renderer is not a required component of the parser. They can be replaced or rewritten. For example, if you have an API with similar functions and hardware acceleration, it is better to use this API to replace pure software for hybrid rendering (mainly Alpha hybrid. Of course, you can also use intel SSE/sse2 to write optimized Renderer. Other rendering functions of render are based on these simple classes.
When we describe an object that is deprecated, we first need to raster it. The main raster Technology in linear is based on scanline. That is to say, a polygon is first converted into many horizontal scanning lines, and then these scanning lines are drawn one by one. Similarly, scanline Rasterizer is not the only class that can be used to generate a horizontal scanning line (scanline). You can also use some containers, or even your own super-ultra-mega Rasterizer.

The scanline container is used for Information Conversion from Rasterizer to scanline Renderer. A scanline consists of many horizontal and non-Intersecting spans. These spans are sorted by the X axis. This means that the sorting operation is not provided, and the order must be processed properly when the span is added to scanline. If the order is not arranged as required, undefined behaviors may occur.

There are three scanline containers in container.

1. Scanline_u-unwrapped scanline container.
2. Scanline_p-the packaged scanline container.
3. Scanline_bin-original, "jagged" scanline container.

The first two containers can contain the de-sawtooth information. The third container cannot.

Important information!
All scanline containers are optimized for speed, but memory usage is not considered. In fact, they will apply for memory for the worst case, so the overhead is a bit high. If you only use a small number of scanlines, this will not become a bottleneck, but it may not be a good idea to use scanline arrays to store the entire shape, because this will use the amount of memory that exceeds the size of the result image.

The difference between packed scanline and unpacked scanline is that unpacked scanline always saves the coverage value for all pixels ), includes pixels that are all covered in the interior of a polygon. Packed scanlines Combines pixels with the same coverage value into solid span.

It seems that using the packed version of scanline is always better, but not in practice. But when you render some large solid multi-side shapes, it will be faster to use scanline_p because the multi-side shapes are much larger than the perimeter (measured from the pixel perspective ). However, scanline_u should be used for rendering characters, so that less span can be processed. (scanline_u will generate about three times less span than scanline_p, the number of spans is an important overhead. Similarly, in most span generators (such as gradients, Gouraud shader, and image generators), the number of spans is even more important, therefore, scanline_p is generally not used.