1,554
edits
Difference between revisions of "OpenTasks"
Jump to navigation
Jump to search
Add rendering pipeline task
(Moved tasks taken at GSoC2007 to separate page) |
(Add rendering pipeline task) |
||
| Line 87: | Line 87: | ||
* There are [[GUI_Themes/TODO|a number]] of small things to do which will make GUI behavior more predictive | * There are [[GUI_Themes/TODO|a number]] of small things to do which will make GUI behavior more predictive | ||
* Modern Theme renderer should be reworked to make it faster, for example currently shadow drawing is rather slow (and hacked) | * Modern Theme renderer should be reworked to make it faster, for example currently shadow drawing is rather slow (and hacked) | ||
=== New Rendering Pipeline === | |||
''Technical Contact'': [[User:Fingolfin|Max Horn]], [[User:Sev|Eugene Sandulenko]] | |||
''Background:'' | |||
SDL backends is used by most of our backends. The current rendering pipeline in the SDL backend is rather convoluted and complex. It could certainly benefit from a thorough overhaul. But this is not an easy task, given the number of extra features one has to support: 8->16bit conversion, scaling, aspect ratio correction (in place), separate mouse cursor scaling, separate mouse palette, screen shaking, and of course the (GUI) overlay. | |||
''The Task:'' | |||
Take SDL backend, remove all current dirty rectangles code and implement proper dirty areas detection. That is, it keeps a copy of the last rendered frame, then when updateScreen() is called compares the current against the previous frame, and from this automatically computes which pixels have to be updated. Then we could run some performance comparisons; in particular it would be interesting to learn how this affects CPU and RAM usage (of course we'd need an extra buffer for the prev frame, but maybe we can save in other places). | |||
There are various details to consider for this, of course: Scalers usually look at multiple input pixels to compute their output, so whenever the autodirty code sees a changed pixel, it may also have to dirty neighboring pixels. One way to do that w/o having to look at all input pixels multiple times would be to compute a "dirty bitmap", where for each pixel we keep a single "dirty" bit. Yes, more memory again -- it's a speed vs. memory tradeoff, and I am not sure which resource is more important in this case (and this might vary from architecture to architecture), so some experiments might be necessary. | |||
Also, one has to decide what is better: Keeping the prev frame before or after the 8->16bit conversion. The former takes up less space and potentially allows us to avoid converting certain pixels from 8 to 16 bit; OTOH, the latter approach gives us perfect "palette change handling" for free (for example right now in games which do color rotation, we always invalidate the whole screen in the SDL backend, even if perhaps only a few pixels changed at all). | |||
But automatic dirty updates might not be ideal for all backends, so keeping an (optional) dirty rect API might still be a good idea (right now we have this implicitly via copyRectToScreen/ copyRectToOverlay; in the future this *might* be phased out (nothing has been decided yet, though), but then we could still keep a markRectAsDirty() method (which on backends doing auto-dirtying would simply do nothing). | |||
== Audio related tasks == | == Audio related tasks == | ||