Difference between revisions of "OpenTasks"

Jump to navigation Jump to search

OpenTasks (view source)

Revision as of 14:23, 28 March 2008

2,614 bytes removed ,  14:23, 28 March 2008
→‎New Rendering Pipeline: removed
m (Reverted edits by Fingolfin (Talk); changed back to last version by Kirben)
Line 83: Line 83:
* Extendible design, which should make it easy to support new widgets
* Extendible design, which should make it easy to support new widgets


=== 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 previous 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 neighbouring 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 previous 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).


=== Virtual Keyboard and Keymapper ===
=== Virtual Keyboard and Keymapper ===
Fingolfin
1,079

edits

Retrieved from "https://wiki.scummvm.org/index.php?title=Special:MobileDiff/8754"

Navigation menu