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