Re: [gtkmm] display of video images, threads

[Carl Nygard <cjnygard fast net>]

On Fri, 2002-08-23 at 13:38, Enrico Costanza wrote:
> Dear All,
>
> I am trying to write a (simple) application to get images from video4linux 
> (process) and display them in a window.
>
> I have inherited from a Gtk::Window, and in this I have a button and a 
> DrawingArea (in fact a class inherited from it).
>
> In "myDrawingArea" I have overridden the expose_event_impl: so that it uses 
> gdk_draw_rgb_image to draw an image buffer.
>
> On the button click the program initializes the video4linux device, grabs an 
> image, puts it the imagebuffer and then it calls queue_draw().
> This works fine.
>
> The problems start if I insert a loop so that on button click the program 
> grabs and displays N images. At first I tried to simply loop grabbing and 
> queue_draw(), but the application only displayed the last frame acquired. 
> I do not understand why: can anyone help?
I'm guessing that you don't relinquish control to the Gtk::Main loop to
process the queue_draw() events.  So when it finally draws, you've
already set the last image as the "current" image.  That last image is
probably drawn N times (unless the event queue is smart enough to
compress sequential queue_draw events into one).

There have been other threads on this list about processing the queue.

This from ERDI Gergo about forced redraw of window:

while (Gtk::Main::events_pending ())
        Gtk::Main::iteration ();


> Then I used gdk_draw_rgb_image directly in the click callback function, and it 
> works, BUT I have some (refresh?) problems: 
> at 640x480 the part of the image below a line at 2/3 is delayed (or at least 
> this is the impression it gives me)
> at 320x240 I have a similar effect, but rather than having a fixed part 
> delayed I have a line scanning throuh the image
> at 160x120 the display is fine
>
> The video is noticeably delayed. e.g. pointing the camera at someone talking 
> the images on the computer go out of synch with reality.

I would ask, can you:

a) Capture at a rate that matches reality?
b) refresh a canned set of images at some framerate (that matches
reality)?
   b1) You'd have to be able to refresh faster, actually, to allow for
the capture time.


You might have to tune your display framerate to your capture rate.

> How can I improve the situation? (I already use double buffering for 
> acquisition, so I suspect the problems come from display)
>
> Shall I use threads so that I start displaying while I am still capturing?
> If so where can I find some documentation about this? 
>
> I have seen threads in Java, but never in c++. Is it common to use threads 
> with gui, for example to start a process and at the same time keep the gui 
> responsive?

Yes, there are plenty of threads used, and many messages, mostly from
Paul Davis (I think).  I thought I saw mentioned there might even be a
faq about it.  Read the archives.

Regards,
Carl