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.
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 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.
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.
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.
Frantisek
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@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers
_______________________________________________
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers
