Re: Efficient image drawing

[Paul Davis <pjdavis engineering uiowa edu>]

Paul Davis wrote:

> Paul Davis wrote:
>
> > John Cupitt wrote:
> >
> > > On 4/27/06, Paul Davis <pjdavis engineering uiowa edu> wrote:
> > >  
> > >
> > > > I'm developing a video playback app and I'm a bit curious to see if
> > > > there's a better way to render images to the screen.  As it is now I'm
> > > > using the Gtkmm objects and copying images from my non-standard format
> > > > in a GdkPixbuf and then drawing to a GtkDrawingArea using
> > > > gdk_draw_rgb_image_dithalign.
> > > >
> > > > Admittedly, this method is fairly fast.  I'm getting between 15 and 20
> > > > fps on my development machine which is only a 1.4 GHz.
> > > >
> > > > I'm just wondering if anyone knew a more efficient method to get image
> > > > data from disk to the screen.  Any suggestions are welcome.
> > > >   
> > >
> > >
> > >
> > > I think gdk_draw_rgb_image_dithalign() is about as fast as you can get
> > > while staying within the world of gdk. I avoid a copy by having my
> > > non-standard format be 24-bit RGB and drawing directly from that, but
> > > that's it I think.
> > >
> > >  
> > I thought about doing something like this, but trippling the disk 
> > space is pretty much out of the question.  The total space used by 
> > all the data is nearing 1TB (of course, thats in multiple movies).
> >
> > For the moment, I'm not too concerned about being tied directly to 
> > X.  If I can find something that screams through the data, I'd be 
> > willing to put forth the effort to have multiple drawing schemes.  
> > Granted I haven't even thought about porting this to windows yet.  
> > Thats somewhere on my TODO list, but not quite at the top.
> >
> > > I don't know if gdk_draw_rgb_image_dithalign() uses the XVideo
> > > extension, but I imagine not. Of course using that ties you to X.
> > > Maybe Cairo with a GL backend would be quicker? Though it'll be a
> > > while before that is a common target :)
> > >
> > > John
> > > _______________________________________________
> > > gtk-list mailing list
> > > gtk-list gnome org
> > > http://mail.gnome.org/mailman/listinfo/gtk-list
> > >
> > >  
> >
> > _______________________________________________
> > gtk-list mailing list
> > gtk-list gnome org
> > http://mail.gnome.org/mailman/listinfo/gtk-list
> I just thought I'd share what I've found with you guys.
>
> My conclusions up front: Using gdk_pixbuf_new_from_data correctly is 
> as fast as you can get.
>
> These are the results I've found:
>
> On an X display with 24bpp,
>
> Using GdkImage and doing a memcpy directly into the structure, i was 
> getting 23-27 fps.
> Using gdk_pixbuf_new_from_data and reusing the same data buffer, i get 
> a solid 28 fps.
>
> And the weird part( in my mind ):
>
> On an X display with 16bpp, using gdk_pixbuf_new_from_data I get a 
> solid 33fps.
>
> It should be shared memory access, and seeing as I give it a 24bpp 
> array, I imagine its got to be doing some sort of memory operations.  
> My random guess is that there's a requisite memory operation somewhere 
> in the pipeline and 24 - 16 is faster than 24 - 24 bpp. If anyone 
> happens to know the reason off the top of their head, I'd be 
> interested in hearing it.
>
> I'm not exactly sure what I was doing before that slowed me down.  My 
> program has a requisite 8bpp - 24bpp transformation.  Before, I was 
> creating a Pixbuf (once) and then on every frame update, doing the 
> transform directly into the pixbuf data array.
>
> Now I do a create_from_data (once) on a buffer I allocate, and then do 
> my transform into the array. And its almost a 100% increase in 
> performance.  I don't get it, but I'm happy.
>
> Thanks for your help,
> Paul Davis
Numbers for 16 and 24 bpp.

> Visual 0x27, type = direct color, depth = 16, f800:7e0:1f; score=8100
> Visual 0x28, type = direct color, depth = 16, f800:7e0:1f; score=8100
> Visual 0x29, type = direct color, depth = 16, f800:7e0:1f; score=8100
> Visual 0x2a, type = direct color, depth = 16, f800:7e0:1f; score=8100
> Visual 0x23, type = true color, depth = 16, f800:7e0:1f (system); 
> score=8111
> Visual 0x24, type = true color, depth = 16, f800:7e0:1f; score=8101
> Visual 0x25, type = true color, depth = 16, f800:7e0:1f; score=8101
> Visual 0x26, type = true color, depth = 16, f800:7e0:1f; score=8101
> Chose visual 0x23, image bpp=16, lsb first
> Color test time elapsed: 0.89s, 112.7 fps, 34.63 megapixels/s
> Color test (dithered) time elapsed: 1.55s, 64.5 fps, 19.82 megapixels/s
> Grayscale test time elapsed: 0.91s, 110.4 fps, 33.92 megapixels/s
> Grayscale test (dithered) time elapsed: 1.78s, 56.3 fps, 17.31 
> megapixels/s
>
> Visual 0x27, type = direct color, depth = 24, ff0000:ff00:ff; score=9100
> Visual 0x28, type = direct color, depth = 24, ff0000:ff00:ff; score=9100
> Visual 0x29, type = direct color, depth = 24, ff0000:ff00:ff; score=9100
> Visual 0x2a, type = direct color, depth = 24, ff0000:ff00:ff; score=9100
> Visual 0x23, type = true color, depth = 24, ff0000:ff00:ff (system); 
> score=9111
> Visual 0x24, type = true color, depth = 24, ff0000:ff00:ff; score=9101
> Visual 0x25, type = true color, depth = 24, ff0000:ff00:ff; score=9101
> Visual 0x26, type = true color, depth = 24, ff0000:ff00:ff; score=9101
> Chose visual 0x23, image bpp=32, lsb first
> Color test time elapsed: 1.29s, 77.8 fps, 23.90 megapixels/s
> Grayscale test time elapsed: 1.26s, 79.2 fps, 24.33 megapixels/s

I'm fairly certain the bottle neck is my zlib decompression.  Granted I 
haven't done any profiling yet.  I'll get on that in a bit.

I am noticing that in 16bpp, doing no dithering is twice is fast.  I'm 
using gdk_draw_rgb_image_dithalign with GDK_RGB_DITHER_NONE.  I wonder 
if replacing this method with one of the others will speed things up 
even more.

Let me know if you see anything interesting.

Paul