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

Re: Image drawing throughput

Paul Davis wrote:


Rose,

I'm not exactly sure what your question is about the timings.  I've got
it down to:

A) How do I know when to update the image?
B) How do I measure how fast the images are being updated?

But it doesn't really matter cause I do both with the same code.

Basically the only "Aha!" part was when I found this:
Glib::signal_idle().connect( sigc:mem_fun( *this, &lsdcasViewer::OnIdle ) ) ; 

Then all I do is use a struct timeval state variable ( along with some
other less interesting stuff, like a boolean that reflects if the movie
is currently in playback )

Then everytime the OnIdle gets signaled you just check if your playing,
and if so, you see if enough time has passed to update the next frame.
I have a user controllable frame rate I should mention.  Sometimes its
helpful for my app to play back video slowly for the types of analysis
we're doing.

Anyhow, when I printed the FPS values, I just did the math and wrote to
stderr.  My controls allow a FPS to be set to 50, but I don't drop
frames, so the computer tops out its refresh at about the 33 fps.
Although its really really touchy.  I had a bit of code that I think was
creating a lot of cache misses in one of my copy operations and it
dropped the frame rate back down to 17, but its all better now.

Oh, and for a bit more information, before I mentioned that I had an old
Motif App that could play through the movies rather quickly because ( I
assumed ) it was going directly to the XImage routines.

Well, I got it compiled and running with LessMotif on the same
computer.  It tops out at 33fps, but actually will slow down every so
often for 5 - 10 frames ( nothing you can notice with your eyes ) but
Gtkmm doesn't.

And I can do it using the Pixbufs.

Oh and when printing out fps to the terminal, it helps to redirect the
output to a file, otherwise the I/O to the screen slows down frame rates.
Now is when I look back at the original question to see if I answered it... 

Oh, and I kinda didn't.  In order to get decent timings, use
gettimeofday function from sys/time.h

It uses the struct timeval format which includes seconds and
microseconds.  So if you can handle only having precision to a millonth
of a second, it should be what you need.

Although I heard that it doesn't exist on windows.

If thats the case, I dunno what to say cause I've never developed for
windows.
Just thought to myself, if this is the case, I'd create a "pulse thread". Something that just increments a read only counter every however often. Then you can just your on idle to figure out if its changed and if so, update the image.
This is assuming that the select( NULL, NULL, NULL, &timeval_var ) trick works on windows. If not, then thats 0 for 2 ideas which would make this attempt at redemption more like digging the hole even deeper. 

Yep...


Oh, and when you mention time drift, I'm not exactly sure what you
mean.  If you're worried about making sure that you're running through
the movie at a consistent rate you'll have to get into more advanced
types of things like frame dropping and time coding.  Neither of which
I'm very familiar with.

Well, frame dropping wouldn't be too hard.  In your idle function, you
could calculate what frame you should be on, seek to it and display it.
Dunno how that'd look durring play back though.

Thats probably enough rambling for one email.  Let me know if you have
any other questions.

Oh, and I cc'd the list in case anyone else was reading along.

Cheers,
Paul

Rose Cumming wrote:


Hello Paul,

The application that I worked on for a company has a similar context.
I got the following approach to work pretty well in the application.

To answer your question:


So anyhow, my question is basically, is there a good way to get at the
underlying XWindows objects to try and avoid the copying operations? As 
it is now, I got from an 8bit image, to 24bit ( my code ) and then use
Pixbuf::create_from_data




You can try:

// this is for the underlying GdkImage
#include <gtk/gtk.h>

Glib::RefPtr<Gdk::Image> imageSurface_;

imageSurface_ = Gdk::Image::create(Gdk::IMAGE_FASTEST,
                                                   get_default_visual(),
                                                   widthOfSurface,
                                                   totalNumberOfLines);

GdkImage* imageSurface = imageSurface_->gobj();
unsigned int* sceneBuffer = (unsigned int *)imageSurface->mem;

Use the sceneBuffer pointer and convert your pixel data to 32-bit RGB.
This allows you to put your image pixel value more directly
(avoid copying and conversion done in pixbuf)


I do have a question for you.
I'm working on improving the timing of my application.
How do you measure 20-30 fps?

Even if you use the standard Gdk::Pixbuf approach,
do you use the Glib::signal_timeout for some regular timing for drawing a frame?
Is there a better way thread/sleep and work with the Gtk main loop to get a frame on display? (I want something more like real-time and taking into account of time drift) 

Thanks,
Rose







-----Original Message-----
From: gtkmm-list-bounces gnome org [mailto:gtkmm-list-bounces gnome org] 
On Behalf Of Paul Davis
Sent: April 26, 2006 12:29 AM
To: gtkmm-list gnome org
Subject: Image drawing throughput


I know this topic has had the occasional beating, but I wanted to put
out a feeler to see if anyone has some insight into the more efficient
meands of drawing images.

Currently, I'm going the route of using a Gtk::DrawingArea and
Gdk::Pixbuf.  Currently, I'm getting frame rates of about 20-30 fps.

The only thing is, I've got an old OpenMotif program ( that I didn't
write ) thats probably upwards of 50 fps.  And before you all start
going on about how 20-30 is respectable, I'm mostly asking because I'm
gonna be adding some stuff that will slow down the whole process ( image 
processing stuff not associated to the actual drawing ) and if I can
squeeze a bit more performance out of the drawing, that'd be helpful.

So anyhow, my question is basically, is there a good way to get at the
underlying XWindows objects to try and avoid the copying operations? As 
it is now, I got from an 8bit image, to 24bit ( my code ) and then use
Pixbuf::create_from_data
Now ideally reading from disk directly into the pix buf would be nice, ( 
but my images are in a non standard format for various reasons ).

Anywho, basically, I'm just asking if anyone knows of a good way to
speed up this type of operation.  And I don't mean cause its flickering
and absolutely sucks.  I'm talking about boring pistons to get those
extra few CC's of power.

Any ideas are welcome
Paul Davis
_______________________________________________
gtkmm-list mailing list
gtkmm-list gnome org
http://mail.gnome.org/mailman/listinfo/gtkmm-list




_________________________________________________________________
MSN® Calendar keeps you organized and takes the effort out of scheduling get-togethers. http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=http://hotmail.com/enca&HL=Market_MSNIS_Taglines Start enjoying all the benefits of MSN® Premium right now and get the first two months FREE*. 




_______________________________________________
gtkmm-list mailing list
gtkmm-list gnome org
http://mail.gnome.org/mailman/listinfo/gtkmm-list
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]