[maemo-developers] [maemo-developers] SDL, Re: SDL vertical blank (vbl) sync.

From: Tapani Pälli tapani.palli at nokia.com
Date: Wed May 31 09:08:26 EEST 2006
ext Frantisek Dufka wrote:
> Eero Tamminen wrote:
>> Hi,
>>> Yes. So to draw without tearing effect either X of framebuffer driver
>>> should report when to draw (vblank period or which line is currently
>>> drawn by hardware)
>> Another possibility is that (SDL) application could ask X server to
>> ask Framebuffer to flush the framebuffer contents to the LCD controller
>> when it's done with a frame.  It might even do that directly by calling
>> the fb ioctls (if there would be such ioctl and it would have access
>> rights to do it).
>> AFAIK the framebuffer doesn't have constant update rate to the LCD and
>> it doesn't immediately push every framebuffer update to the LCD
>> controller.
>> It does updates only if the framebuffer contents have been updated
>> (there's an ioctl to tell that) and there's a certain amount of time
>> since last update.  So, if application could force the framebuffer
>> flush, it would have time to update the screen before the next
>> (automated or application forced) flushing happens.
> Yes, that would be enough too. In fact that's what Kuisma Salonen
> already mentioned yesterday - synchronization in the driver. Now I see
> it too.

Yep, normally clients should not bother too much about sync.

> As for the manual vs automatic updates, that brings another question.
> How often is the screen really updated? I saw in the kernel source
> there is manual vs automatic update mode but which one is actualy 

We are updating areas (dirty-rects), it would hog the memorybus if we
would be updating whole screen all the time.

> enabled? With automatic updates in some intervals it would really not
> matter how fast you can blit to the SDL surface when the data will not
> actually make it to the screen.
> And when talking about SDL, how it is in fact optimized for N770? As
> there is no source for SDL in the maemo repository, is it a stock SDL
> over X? Maybe one using directly kernel framebuffer ioctls would be
> better, at least in full screen.
X needs to know about this anyway, so there should be X extension for
this kind of activity.

> Maybe that is what the video player does. It draws black rectangle via
> GTK/X and then accesses kernel framebuffer directly (with pixel
> doubling, and maybe even direct YUV blits). This would explain why it
> displays black rectangle when you bring up the menu in non-fullscreen
> mode. Optimizing SDL to use same methods would make it the best way to
> access the video hardware.

Videoplayer tells X (using Xsp extension) which rectangle it's updating
and after that X takes care of overlaps. If somethings going to overlap
the video-area, it will tell videoplayer to stop. I'm not very convinced
that we should have this kind of interface for SDL. Do you think
blitting is too slow now? I don't think X is  there the bottleneck at
all, the true bottleneck is the memorybus.

> And as for the sound, how SDL uses sound hardware? SDL is not
> mentioned in
> http://www.maemo.org/platform/docs/multimedia/multimedia_architecture.html
> Does it go over esound?
> Is SDL supposed to be first class citizen in Maemo or it is there just
> for quick game ports but is actually expected to be slower?
> I'm asking because audio seems to lag a bit (in scummvm) and the same
> problem is mentioned in port of Flite TTS which solved it by moving
> from SDL to gstreaemer.

Kuisma can answer the audio questions :-)

> Frantisek

// Tapani

>>> or the controller has to have two buffers so single
>>> or multiple SDL_UpdateRects could be pushed to visible screen in one
>>> operation (SDL_Flip) in appropriate moment. 
>> Cannot/doesn't SDL do double buffering by itself when asked?
>> (it would be much slower if it's done in the normal RAM where
>> the framebuffer resides, but at least there wouldn't be tearing. :))
>>     - Eero
>> _______________________________________________
>> maemo-developers mailing list
>> maemo-developers at maemo.org
>> https://maemo.org/mailman/listinfo/maemo-developers
> _______________________________________________
> maemo-developers mailing list
> maemo-developers at maemo.org
> https://maemo.org/mailman/listinfo/maemo-developers

More information about the maemo-developers mailing list