Namespaces | Defines | Functions

Renderer_ogl.cpp File Reference

The OpenGL renderer and related code. More...

#include <cstring>
#include <cmath>
#include <boost/scoped_ptr.hpp>
#include "smart_ptr.h"
#include "swf/ShapeRecord.h"
#include "gnash.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"
#include "Renderer_ogl.h"
#include <boost/utility.hpp>
#include <boost/bind.hpp>
Include dependency graph for Renderer_ogl.cpp:

Namespaces

namespace  gnash
 

Anonymous namespace for callbacks, local functions, event handlers etc.


Defines

#define NO_ANTIALIASING   1

Functions

point gnash::middle (const point &a, const point &b)
void gnash::trace_curve (const point &startP, const point &controlP, const point &endP, std::vector< oglVertex > &coords)
std::vector< oglVertex > gnash::interpolate (const std::vector< Edge > &edges, const float &anchor_x, const float &anchor_y)
bool gnash::isEven (const size_t &n)
template<typename C , typename T , typename R , typename A >
void gnash::for_each (C &container, R(T::*pmf)(const A &), const A &arg)
Renderer * gnash::create_Renderer_ogl (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!


Define Documentation

#define NO_ANTIALIASING   1

Variable Documentation

boost::scoped_ptr<image::GnashImage> _cache
const SWFCxForm& _cx
std::vector<boost::int16_t>& _dest
bool _disposed
boost::scoped_ptr<image::GnashImage> _img
GLenum _ogl_img_type
size_t _orig_height
size_t _orig_width
GLenum _pixel_format
Renderer& _renderer
GLuint _texture_id