Hi,
I want to move discussion about specific render handler redesign steps
in here.
Currently my plan is as follows:
- Implement a new, intermediary render_handler_impl class which acts
as a backward compatibility class (and base class for any
triangle-based renderer such as any hardware acceleration). It's a
descendant of the render_handler class.
- Low-level virtual methods would be moved to this class, not kept
in the base render_handler class and thus are shielded from the rest
of the Gnash source. These methods should only called from within
the renderer itself:
set_matrix (?)
set_cxform (?)
draw_mesh_strip
draw_line_strip
fill_style_XXXXXX
line_style_XXXXXX
draw_bitmap (only used for glyphs!)
- Instead, the base class (render_handler) defines a new method:
virtual void draw_shape_character(shape_character_def *def,
character *inst) = 0;
It must know how to draw a shape character. Note that a bitmap
placed on the stage is just a rectangle with bitmap fill style, so
draw_shape_character() can automatically draw bitmaps too.
- to support drawing of glyphs another method is defined:
render_handler::draw_glyph(shape_character_def *def,
const matrix *mat) = 0;
It's very similar to draw_shape_character except that it does not
get passed an instance. It will be processed in a very similar way,
however.
- render_handler_impl:draw_shape_character() (the one used for
compatibility) will use the old "mesh_set" class to tesselate the
shape. It will call the old draw_mesh_strip() and friends so
backends should work straight out of the box.
- shape_character_def::display() is very simple now:
void shape_character_def::display(character* inst)
{
render_handler* renderer = get_render_handler();
renderer->draw_shape_character(this, inst);
}
- I already implemented (without cache) this compatibility method and
it seems to work well. However, it ends by calling
mesh_set:display() which accesses the renderer methods directly,
which is not good (as these functions should not be accessible from
outside). To change this a few more changes will be necessary -
cannot tell yet.
- A generic base class render_cache_object is declared in
render_handler.h which does not contain much members and can be used
by the renderer to store any kind of caching data. For
render_handler_impl (compatibility) a descendant is defined that
holds mesh sets, just like Gnash does now.
- I'd really like to see AGG to be a fixed, integral part of Gnash so
that it can be used to render font bitmaps for OpenGL and Cairo
backends.
Any suggestions? Problems you see?
Udo
_______________________________________________
Gnash-dev mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/gnash-dev
