Dirty region based rendering (updated from GSOC 2010)

[jmarshallnz]

This pull req pulls in work that topfs2 did in GSOC last year, updated for latest master.

The basic idea is to introduce a Process() routine in CGUIControl et. al. that does most of the heavy lifting, so that Render() is light. Then, we mark whether a control is dirty or not and accumulate up the total region to render so that we can Scissor() that off and only render the small region.

This gives significant savings in both CPU and GPU on all platforms - primarily as the GPU doesn't need to render such a large area.

In the future the plan is to prevent it swapping buffers when we don't need to, and also use the masking to save running through the Render() loop. It is also first steps towards event-based rendering, where the Process() loop will be run only as required, saving significant CPU.

There's still a few controls to tidy up (that are currently marked always dirty) but we feel it will only really get the last niggles worked through if it gets the wider testing that comes from being in master.

[malard]

any plans to squash a lot of the Always Mark foo for now commits etc?

[elupus]

so any known issues with this?

[theuni]

I can't see any reason to squash them. With them broken out it would be much easier to: take a control, see where it's marked to always render, revert, and fix it proper.

[jmarshallnz]

@elupus: Known issues are:

1. Some controls are too conservative (not a regression - they just mark dirty more than they should)
2. We don't respond (yet) to WM_PAINT messages, so a window on top of XBMC may stick around.
3. There's potentially incorrect sizing of regions when 3D rotations are involved (we don't take the camera/projection into account).

[topfs2]

@malard I don't think we will squash those together, they are there mostly to show which controls still need love. If merged into mainline it will be one giant change most likely, so then it doesn't really matter if squashed or not.

elupus, Some controls always mark, i.e. they behave as before. As for regressions most should be gone I think. Anyone who could test and confirm this would be a major help.

[topfs2]

As for nbr 2 on jmarshallnz list. Since we always flip, this should not be a regression. And bobo1on1 have already made a patch for this.

[elupus]

so since we have some regressions (mainly the transform). is the code path optional in that we don't have to do the dirty checks? if so i see no reason not letting it in.

[topfs2]

@elupus, The default path is to do process and mark but always render (and don't scissor anything). So while it does a little bit of extra processing (should be negligible) it will behave as we have right now. To get it to do the actual dirty region scissoring (and possible multiple render passes) one must specify so in as.xml

[pieh]

GUIEditControl wasn't updated and seems not to mark itself as dirty when value is changed (so even initial value isn't visible) - see Settings->Network->Services and port/username/password controls (examples of edit controls)