Re[2]: [Gnash-dev] opengl->agg?

[Udo Giacomozzi]

Hello Martin,

Tuesday, May 8, 2007, 2:02:03 PM, you wrote:
>> (except if you have no MMU).
MG> MMU? Hunh? FPU?

Arrghh. Yes, of course, FPU. Had too many acronyms to fit in one day ;)


MG> BTW do we have an idea how fpu-intensive AGG is?

AGG, the rednering engine itself: not much. Rendering uses integers.
Some vector calculations (calculate the shape of a "line", for
example) use floats.

AGG, the backend, uses lots of FP arithmetic (matrix transformations,
scaling).


MG> I know mad is famed for being fast on integer machines

What/who is mad?


>> I see more potential in improving invalidated bounds calculation since
>> AGG currently is very busy doing useless work (see gotoAndPlay thread).

MG> Like you, I suspect it is more to do with the way we use AGG than agg 
itself.

Mmmh, don't think AGG can be *used* in much different/better way.

Once all vectory are fed to AGG there should not be much more to
optimize. I always choose the fastest AGG method that leads to
correct results.

So, again, vector calculations could be optimized. The AGG engine
comes with a "vector pipeline", we currently don't use. I doubt it can
be much faster than our implementation.

It's all about solving equations (apply scaling to the matrix itself,
rather than multiplying the result).


MG> I know that our handling of cairo is pessimal. swfdec uses cairo and
MG> run like a train whereas ours bloats immensly on many small objects.
MG> I hope you didn't use the cairo code as your pattern for the agg
MG> renderer! :)

Never looked at the Cairo code. Also, the Cairo code is based on the
render_handler_tri, which leaves polygon transformations (solving to
triangles) to Gnash. AGG does this on-the-fly and is probably much
more accurate and faster.

Again, I think we give the renderers much *useless* work to do, and
this is not related how rendering itself is done.

For a more concrete answer I would like to see that movie that shows
such big performance differences.


Udo