Re: [gtkmm] display of video images, threads



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





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]