The OpenGL renderer and related code. More...

#include "Renderer_ogl.h"
#include <boost/utility.hpp>
#include <boost/bind.hpp>
#include <list>
#include <cstring>
#include <cmath>
#include <boost/scoped_ptr.hpp>
#include "swf/ShapeRecord.h"
#include "GnashEnums.h"
#include "RGBA.h"
#include "GnashImage.h"
#include "GnashTexture.h"
#include "GnashNumeric.h"
#include "log.h"
#include "utility.h"
#include "Range2d.h"
#include "SWFCxForm.h"
#include "FillStyle.h"
#include "Transform.h"

Namespaces
namespace	gnash
	Anonymous namespace for callbacks, local functions, event handlers etc.
namespace	gnash::renderer
namespace	gnash::renderer::opengl
Defines
#define	NO_ANTIALIASING 1
Typedefs
typedef std::vector< Path >	gnash::renderer::opengl::PathVec
Functions
point	gnash::renderer::opengl::middle (const point &a, const point &b)
void	gnash::renderer::opengl::trace_curve (const point &startP, const point &controlP, const point &endP, std::vector< oglVertex > &coords)
std::vector< oglVertex >	gnash::renderer::opengl::interpolate (const std::vector< Edge > &edges, const float &anchor_x, const float &anchor_y)
bool	gnash::renderer::opengl::isEven (const size_t &n)
template<typename C , typename T , typename R , typename A >
void	gnash::renderer::opengl::for_each (C &container, R(T::*pmf)(const A &), const A &arg)
Renderer *	gnash::renderer::opengl::create_handler (bool init)

Detailed Description

The OpenGL renderer and related code.

So how does this thing work?

1. Flash graphics are fundamentally incompatible with OpenGL. Flash shapes are defined by an arbitrary number of paths, which in turn are formed from an arbitrary number of edges. An edge describes a quadratic Bezier curve. A shape is defined by at least one path enclosing a space -- this space is the shape. Every path may have a left and/or right fill style, determining (if the path is thought of as a vector) which side(s) of the path is to be filled. OpenGL, on the other hand, understands only triangles, lines and points. We must break Flash graphics down into primitives that OpenGL can understand before we can render them.

2. First, we must ensure that OpenGL receives only closed shapes with a single fill style. Paths with two fill styles are duplicated. Then, shapes with a left fill style are reversed and the fill style is moved to the right. The shapes must be closed, so the tesselator can parse them; this involves a fun game of connect-the-dots. Fortunately, Flash guarantees that shapes are always closed and that they're never self-intersecting.

3. Now that we have a consistent set of shapes, we can interpolate the Bezier curves of which each path is made of. OpenGL can do this for us, using evaluators, but we currently do it ourselves.

4. Being the proud owners of a brand new set of interpolated coordinates, we can feed the coordinates into the GLU tesselator. The tesselator will break our complex (but never self-intersecting) polygon into OpenGL- grokkable primitives (say, a triangle fan or strip). We let the tesselator worry about that part. When the tesselator is finished, all we have to do is set up the fill style and draw the primitives given to us. The GLU tesselator will take care of shapes having inner boundaries (for example a donut shape). This makes life a LOT easier!