> Should DLOP_FIELD_PARITY work exactly the same as with a Matrox card? Should work in a very similar way.
There is one subtlety: when Flip() is called, the Matrox implementation checks that the bottom field is active before flipping the buffers, waiting if necessary. The Unichrome implementation can't make that check (the hardware can't tell you which field it's on) so it's forced to blindly wait for the interrupt that occurs at the start of the bottom field. What this means is that you have a slightly longer period of time to get the next frame ready for the Matrox card. The Matrox implementation might actually cope with you trying to give it 50 frames a second too, but I'm not sure it would work reliably. The Unichrome definitely won't because each Flip() call will return 0.04 secs after the last one when FIELD_PARITY is enabled. Anyway, if either of these issues is what's causing the problem, there is hope, in the form of the enhanced triple buffering patches being discussed on directfb-dev. This removes the need for the DirectFB driver to wait for the right field when using FIELD_PARITY and leaves it to the kernel frame buffer driver to flip the buffers at the right time. I may be able to send you some very rough code to test this but I'd like you to do a test for me first: Remove the Flip() call entirely from your code and instead print out the current time (down to milliseconds, e.g. using gettimeofday). This will confirm what the up-stream code is trying to display. Regards, Mark _______________________________________________ directfb-users mailing list [email protected] http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-users
