Denis Oliver Kropp schrieb: > Yes, pipelined flips were introduced for window updates only, where > the buffers are never swapped but blitted to the display. It was easy > to add pipelined flipping there. Years ago I had a game running on AWT > (on MIPS) using a DirectFB window with looping updates of one region of > the UI, i.e. post another update event in the handler for the update > event. > > The pipelined Flip()s with WaitSerial() gave another 5-10% FPS increase. > It ran at 55 FPS, in a 600x328 portion of the 16 bit window. Of course, > with the command buffer no longer being empty for 0-n milliseconds, > there was much less impact by other running processes. Not that I had > any garbage objects to be collected in the whole "post & handle update - > render objects - handle input & objects" loop. I eliminated those ;)
I have to add: Before I added WaitSerial() and DSFLIP_PIPELINE I had to wait for an idle engine in AWT or use something in the game that needs a software fallback. Otherwise the complete command buffer got filled and the game was very laggy and the timing was irregular, but it was max FPS :) But this only happens with a single buffered layer, e.g. using desktop buffer mode "front only". In the code that does blitting from back to front buffer of a layer using "backvideo", there's an extra wait now. That's all in dfb_layer_region_flip_update(). -- Best regards, Denis Oliver Kropp .------------------------------------------. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | "------------------------------------------" _______________________________________________ directfb-dev mailing list [email protected] http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
