DirectFB - Home of the pragmatist Roadmap

[directfb-users] Re: DFB-SDL speed issue
Mailing List archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[directfb-users] Re: DFB-SDL speed issue

Quoting Ulrich von Zadow:
> I've got a DFB display mixer here that renders quickly in fullscreen 
> mode and slows down when rendering via SDL.
> More precisely, I'm doing software rendering in both cases. I'm 
> compositing stuff on a backbuffer and then blitting the changed regions 
> to the front buffer each frame. Everything except the front buffer is in 
> system memory. In fullscreen mode, this works perfectly, and I'm getting 
> the rendering speeds I expect. When I use SDL, it seems that 
> DLBM_FRONTONLY has no effect - I need to do an additional Flip of the 
> primary surface. That flip obviously isn't a real flip, it blts the 
> complete backbuffer to the frontbuffer instead :-(.

The SDL backend doesn't support direct access to the SDL screen data.
There's always a Flip() required, even in single buffer mode. It copies
the updated region from the DirectFB front buffer to the SDL screen
and calls SDL_UpdateRects().

This is required for the multi application core,
because only the master has control over SDL.

> Is there any way I can blt to the real frontbuffer using the SDL backend?

Use DLBM_FRONTONLY, it's faster if you don't Flip() the whole surface.

Older versions of the SDL backend, i.e. without multi app support, are faster.
See the NEWS file, 0.9.17 might be old enough.

Separate implementations (single/multi) of the SDL backend are planned,
but I have to finish the display layer core refactoring first.

Best regards,
  Denis Oliver Kropp

| DirectFB - Hardware accelerated graphics |
|                 |

                            Convergence GmbH

Info: To unsubscribe send a mail to with 
"unsubscribe directfb-users" as subject.

Home | Main Index | Thread Index / Development / Old Archives