Proposal:Renderer redesign

This article is dedicated to overworking the rendering code of FIFE.

Profiling remarks

• Profiling is done with release builds.
• The following files should be uploaded to the members ftp:

Profiling data

vtchill

System specs

1.8Ghz P4, 2GB RAM, GeForce4 ti4200 (64MB), ubuntu 8.10

Unknown Horizons

1. uh_engine_profile_1 (fife performance data)
2. uh_python_profile_1.svg or uh_python_profile_1.png (Unknown Horizons python performance data)

Zero-Projekt

1. zero_profile_1 (fife performance data)
2. zero_profile_2 (fife performance data)

Profiling Proposal

Too compare two approaches performance wise in the best case only a single number has to be compared. This is not the case with *just* profiling via some tool.

I would propose taking the ratio of the time trunks Camera.render takes to the time an approach takes for the same function as the measure for renderer-performance.

Too get an idea how the different uses of FIFE behave I propose to take the aformentioned measure for the following use case.

• Unknown Horizon the standard map, zoomed out. ~20k static tiles, ~2k trees and 3 moving instances on the same layer.
• Unknown Horizon the standard map, zoomed in.

phoku 17:59, 8 March 2009 (UTC)

Proposals how to redesign

Per Layer Cache: Shortterm Performance Gain

This is a proposal for a refactoring without changing neither the API, nor rewriting large chunks of code. It is aimed at both the SDL and the OpenGL renderer.

Currently each frame all instance per layer are visited and checked for visibility via the a loop inside Camera.render. Every instance has a mapping Camera -> InstanceVisualCacheItem, where geometry information is cached.

Inside the loop three operations are performed: Geometry update, Image update and visibility testing. Geometry is cached inside the aformentioned InstanceVisualCacheItem. The bounding box on screen is calculated from the geometry and the possibly changed image.

The result of this operation is called 'renderlist' in the following. That is, some iterable that contains all instances which need to be drawn in their respective drawing order with up-to-date information inside the InstanceVisualCacheItem.

This redesign aims to first get rid of this loop in the case layers contain only static instances. A per layer 'cache' of the renderlist should be introduced which knows when to recalculate the renderlist, based on information from the camera and the layer.

In the simplest case renderlists are updated whenever anything regarding rendering changes. This already has a huge performance impact for the case of ground layers.

The next step should use the abstraction of the per layer cache to implemented a scheme where the renderlists (or some precursor state from which the renderlist can derived in linear time) are updated on demand, that is only when an instances visual actually changes.

My proposal would be to use a heuristic on-screen bounding box to store the instances in some spatially sorted data structure. And update that data structure in place via the notfification interface from the layers.

This proposal aims to make a *display* of large maps at least feasable, there are two other issues with regards to the total number of instances. First of the Layer.update function is still linear in all instances. Second with zooming the number of instances on-screen can become huge and would need a level of detail approach, which is not easily feasable.

phoku 17:51, 8 March 2009 (UTC)