Opened 9 years ago

Last modified 11 months ago

#5926 new bug

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

Reported by: oco Owned by: korli
Priority: normal Milestone: R1
Component: Kits/OpenGL Kit Version: R1/alpha1
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

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".

Attachments (6)

screenshot2.png (83.3 KB ) - added by oco 9 years ago.
Haiku_teapot_old_laptop_ok.png (72.7 KB ) - added by oco 9 years ago.
Haiku_teapot_old_laptop_ok.2.png (72.7 KB ) - added by oco 9 years ago.
Haiku_new_laptop_dual_core_VESA.png (127.1 KB ) - added by oco 9 years ago.
Haiku_teapot_old_laptop.png (81.6 KB ) - added by oco 9 years ago.
Haiku_Beta1_teapot_same_new_laptop_8_Years_later.png (103.9 KB ) - added by oco 11 months ago.

Download all attachments as: .zip

Change History (12)

by oco, 9 years ago

Attachment: screenshot2.png added

comment:1 by anevilyak, 9 years ago

Component: Applications/ScreenshotKits/OpenGL Kit
Owner: changed from nobody to korli

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.

comment:2 by phoudoin, 9 years ago

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

comment:3 by oco, 9 years ago

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.

by oco, 9 years ago

Attachment: Haiku_teapot_old_laptop.png added

comment:4 by phoudoin, 9 years ago

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...

comment:5 by stippi, 9 years ago

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.

comment:6 by oco, 11 months ago

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)...)

Note: See TracTickets for help on using tickets.