Re: [gtk-list] gtk_preview_draw_row too slow



>  This two calls
>  
>    gtk_preview_draw_row (GTK_PREVIEW (preview),
>  			&(buf[FRAME_SIZE * frame]), 0, 0, FRAME_SIZE);
>    gtk_widget_draw (preview, NULL);
>  
>  with FRAME_SIZE = 352*288 byte in a gtk_timeout_add(20, [...]) (50
>  calls per second) take aproximately 25% of a PII 333 with Millenium-1
>  in hicolor (16 bit).
>  
>  I think that is much too much! I have an simple old tool, that does
>  something similar and it uses nearly no cpu, because it loads all
>  frames into the X server. That has the disadvantage of blowing up the
>  memory usage of the X server, because the video data is only gray, but
>  the X server runs in 16 bit.
>  
>  Does anybody know a faster way to push video data into a X-Server?

This is slow because GtkPreview renders the RGB image into the proper
X image representation every time it puts stuff to the screen.  It
also has to transfer things to the server (it is very fast if you are
on the same machine, as it can use MITSHM, or slow if you are working
over the network).

If you can pre-calculate all your frames, then you could do the
following.  Create a GdkPixmap for every frame, and use
gtk_preview_put() to render each frame into a separate pixmap.  When
you want to paint a frame to the screen, simply use gdk_draw_pixmap().
This will require more memory on the server but it will be a lot
faster, as the pixmaps live on the server.

(In this last case, you could also use gdk_imlib, which is a bit
easier for rendering RGB data than using gtk_preview).

  Federico



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