Taking a screenshot of an opengl animation give you some kind of "interlaced" image

[oco]

It seems the screen shot mix two succesive images (see attached file). I am not sure it is the intended behavior despite it give an artistic touch.

I also notice a few second slow down while taking the screen shot. On my ten years old computer with BeOS R5, there is only one short stop in the animation while taking the screenshot, and the image is "atomic".

[anevilyak]

That might be some form of quirk with OpenGL's buffer swapping. In any case, in terms of time taken the two aren't really comparable, since BeOS 5's screenshot function was hardwired directly into the app_server and only did a TGA dump, whereas ours loads a full app which has a number of other capabilities, which is probably where your perceived slowdown is coming from. In any case, I can't reproduce this behavior with GLTeapot or any other OpenGL app I have here currently.

[phoudoin]

Could you share your Free Pascal GLUT demo so we can eventually reproduce the bug?

[oco]

Oh ! I forgot to look at comments.

The freepascal demo is here : ​http://olivier.coursiere.free.fr/screenshot/haiku_glutdemova

I can reproduce with GLTeapot with my two laptops. But the problem is not always noticeable on the old one (single core AMD 64 with nvidia supported card). And there is only one stop while taking the screenshot. I always reproduce the problem on my core2 duo in VESA mode. Maybe it is VESA and/or multi-threaded related.

I will add some more screenshots.

[phoudoin]

Hi/Salut Olivier,

I guess each time the OpenGL object is in motion, right?

My bet is, on a multi-cores system, while the screenshot is taken (ReadBitmap) by app_server, the next rendered frame drawing is already in progress, and some range of the frame buffer are committed, others not yet, hence the "interlaced" visual effect.

And the more the machine support hardware parallelism, the more the issue is possible.

As François once proposed, one solution could be that the screen capture hold the direct mode lock so no direct mode drawing could screw the capture meanwhile...

[stippi]

Yes, that's exactly what needs to happen. It's not so much a lock, I believe, but a message to the client, which then grabs a lock, which must block the thread until the screenshot is taken. It should be sufficient to look at what happens when the clipping regions for all windows changes, and come up with something similar for the ReadBitmap() invokation.

[oco]

It looks that this problem was either fixed or optimisations make the problem more difficult to reproduce even if i tried many times (if frame rate is correct in teapot, it looks like teapot run 4 times faster than 8 years ago on the same hardware (Vesa driver)...)