gnash-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnash-dev] Gnash tutorial on profiling the renderer


From: Udo Giacomozzi
Subject: Re: [Gnash-dev] Gnash tutorial on profiling the renderer
Date: Sat, 25 Apr 2009 15:17:27 +0200

Hello Kristian,

Friday, April 24, 2009, 2:02:11 PM, you wrote:
KFE> I have just finished a new tutorial on Gnash's development wiki
KFE> describing how to carry out profiling in Gnash focussed on the
KFE> renderer, so we can hopefully attract some help to improve on
KFE> Gnash's renderer.

With no doubt improvement of the renderers is very important but I
doubt that the profiling movies mentioned on the Wiki page are
suitable for profiling.

In fact they are *very* simple and merely measure how fast the
rendered shapes are pushed to the VRAM.

There are a number of possibilities where the rendering of complex
scenes could be optimized (no matter which renderer) but the profiling
movies would not be able to measure a difference.

For example, the "invalidation bounds" mechanism that improves
rendering speed significantly in many situations is nearly useless for
the profiling movies on the Wiki.

A good profiling movie is not that easy to build and must contain a
variety of typical rendering situations like complex and simple
graphics, static and moving objects, simple and complex fills and so
on. To really compare rendering performance you need to build a movie
that steps through different scenes specifically built for different
situations.

For example, the AGG rendering backend converts every shape on-the-fly
to a AGG data structure while rendering. AFAIK these data structures
still aren't cached. This does not affect the movies on the Wiki page
but I guess shapes with lots of edges could be improved.

As an alternative for a expensive, specifically built test movie I
suggest to measure the performance of ca. 5 very different,
self-running real-world movies. For example Atom Films movies or
similar.


The AGG rendering backend with no doubt could be improved
performance-wise but some improvements are not simple to do. I guess
that's the same for the other backends.

Udo







reply via email to

[Prev in Thread] Current Thread [Next in Thread]