[maemo-developers] SDL, tearing, X overhead and direct framebuffer gfx

[From: Eero Tamminen]

Hi,

I'll comment things others haven't yet commented on.

ext Tobias Oberstein wrote:
> Q: btw - how can I shutdown Maemo Launcher/Hildon/Matchbox/Xomap?
> Whenever I do one of
> 
> /etc/init.d/maemo-launcher stop
> /etc/init.d/x-server stop
> 
> the device will automatically reboot.

Yes, the SW watchdog does that.  You can disable that with Flasher.


> I wondered if there would be any plans to make SDL run directly on
> framebuffer .. if not, I'd maybe give it a try.

That's not really useful for maemo (see below for usability issues).


> Q: Where can I find the sources to the OS2008 SDL?

Where all the other sources are i.e. from the maemo.org repository:
	http://repository.maemo.org/pool/maemo4.0/free/source/libs/


> ## produce ARM11 target optimized code
> ## use hardware FP, but use soft FP ABI for math lib
> ##
> OPT_FLAGS = -O3 -fomit-frame-pointer -mcpu=arm1136j-s -mfpu=vfp
> -mfloat-abi=softfp

To get best performance, it's better to test the options to see what
produces best results (-O3 vs. -O2 vs. -Os, VFP).  O3 bloats code
size which can be bad considering the caches, whether VFP helps depends
on whether you use it on cross-library calls to libraries that are
non-VFP.


> ===> Source:
> 
> //
> // minimal timer based SDL fullscreen test for N800
> //
> // the test seems to indicate 2 problems:
> //
> //   1) heavy tearing
> //   2) significant overhead due to X server (rendering pipe is : SDL ->
> X -> Framebuffer)

You do just memset to shared memory area whereas X needs first to blit
that area to window with clipping before requesting framebuffer to
transfer the changed area to LCD.


> //////////////////////////////////////////////////////////////////////////
>    //
>    // setup X stuff (we pull up a "pseudo X window" in fullscreen, so our
>    // framebuffer graphics will not be overwritten by X server - otherwise
>    // we had to shutdown X server).
>    //
> 
> //////////////////////////////////////////////////////////////////////////

Or you could switch to a different VT.  Writing directly to framebuffer
is really ugly when you're running X server.  If user presses power or
Home key, or there's some system banner, you'll be overwriting the
window that came on top.  Or if uses switches to Home with long press
of Home key, user will be very confused...

(There's a good reason why X needs to copy your changed data to
the screen window with clipping.)


>    for (n = 0; n < LOOPN; ++n)
>    {
>      // wait for fb->lcd video ram transfer complete
>      ioctl (fbfd, OMAPFB_SYNC_GFX);
> 
>      // "render" whole frame in single color
>      memset (fbp, n, ssize);
> 
>      // wait for vsync
>      ioctl (fbfd, OMAPFB_VSYNC);
> 
>      // request transfer of fb-> lcd video ram for whole screen
>      ioctl (fbfd, OMAPFB_UPDATE_WINDOW, &update);
>    }

As there's no real VSYNC, the framebuffer itself could be discarding
some of your updates (at least it did it earlier (in 770), I'm not sure
about the latest releases) which affects the perceived performance.


	- Eero