[Top][All Lists]
[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