Re: [MiNT] Menu redraw

[Eero Tamminen <oak@helsinkinet.fi>]

Hi,

On maanantai 25 maaliskuu 2013, Ole wrote:
>  Am Montag, den 25.03.2013, 09:16 +0100 schrieb Eero Tamminen
> > There may also be multiple of them so that one can be drawn to/from
> > while
> > other is locked, or e.g. one per layer in the HTML page (with GL
> > stuff
> > doing compositing from them).
> 
>  But than you don't just blit on scroll events (you said, it is required
>  for smooth scrolling...).

Blit from multiple (non-overlapping) buffers is still blitting
and much more lightweight operation than rendering text character
at the time (for accurate positioning), rendering HTML 5 video frames etc.

Use of intermediate buffer adds an extra memory read & write for
that data.  That's a performance optimization only if it saves
larger amount of reads & writes elsewhere, which is the case
if screen needs to, and *can* be updated (when scrolling) at much
faster pace than the content changes.

If there isn't enough CPU power to keep up even with the content updates,
then the use intermediate buffer(s) isn't a performance win.  That might
be the case with Firebee.


	- Eero

In case of layers, it's compositing (not blitting) and done with
GL shader programs which just get texture (buffer) addresses. That's
something that requires GLES v2 or better gfx HW (present in modern
phones on PCs) though, so it's not relevant for Firebee.