[Mesa-dev] [RFC] st/vega: Clean up and OpenVG 1.1

[Keith Whitwell]

On Tue, 2010-11-30 at 01:51 -0800, Chia-I Wu wrote:
> Hi list,
> 
> I have spent the weekend adding OpenVG 1.1 support to Vega state
> tracker.  The new features added include mask layer support, text
> support, and a new color transformation stage.  The work can be found
> at
> 
>   http://cgit.freedesktop.org/~olv/mesa/log/?h=vega-1.1
> 
> vega-1.1 branch is based on another clean-up branch
> 
>   http://cgit.freedesktop.org/~olv/mesa/log/?h=vega-polish
> 
> Vega employs a renderer to submit its rendering commands to the pipe
> context.  vega-polish branch mainly introduces "states" to renderer.
> I feel vega-1.1 is more self-explanatory so I will focus more on
> vega-polish.
> 
> The idea of renderer states is that, functions like vgClear or vgMask
> submit rendering commands to the pipe context, but they do not want to
> go through the standard OpenVG pipeline.  Instead of having them
> handle the pipe states save/restore, renderer states allows them to
> switch the renderer to the specific state they need.  For example,
> vgClear can then be implemented by
> 
>   renderer_clear_begin(renderer);
>   renderer_clear(renderer, x, y, w, h, color); // clear a rectangle
>   renderer_clear_end(renderer);
> 
> vgClear does not need to know which pipe states renderer_clear_begin
> sets or which pipe states renderer_clear_end restores.  Nor should it
> care.
> 
> After the addition of renderer states, vega-polish goes on to refactor
> the code in a way that finally the renderer no longer depends on
> OpenVG states and all pipe context state manipulation is done by the
> renderer.  This makes the renderer an abraction of the pipe_context
> for Vega:
> 
>    App -> OpenVG -> renderer -> pipe_context
> 
> The benefits of the changes are that code that handles OpenVG
> functions and code that sets pipe_context is no longer mixed.  Since
> the renderer is an opaque object, its implementation can be changed:
> Use a different pipe_context function for an OpenVG function or the
> frequency of pipe state changes may be minimized.

There's a lot here, but it looks like a good cleanup & really sorts out
the flow of control in that module.

Thanks for giving vega some love...

Keith