Re: Image drawing throughput

[Paul Davis <pjdavis homer biomed-eng uiowa edu>]

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