> > > in GTK3, this is almost certainly not the best way to do this. You want to > use a frame timer based on the refresh/vblank cycle of the monitor.
Yes you're right, I just meant to give the base idea. ..I think that gtk_widget_queue_draw_area() enqueues a redraw at the next frame clock tick, so draws are always done on frame-clock. But I'm not sure, so it's best to base everything on the frame clock anyway. This is what I first tried to do but could not find good information > on it. It seems I need to quickly create and destroy objects no matter > what I do which is why I sent this message. > > I can set an image control's GdkPixbuf but there seems to be no way to > change the data that a GdkPixbuf points to. > Maybe you can try with gdk_pixbuf_new_from_data () <https://developer.gnome.org/gdk-pixbuf/stable/gdk-pixbuf-Image-Data-in-Memory.html#gdk-pixbuf-new-from-data> It may also be necessary > to create another GtkImage to perform double buffering inside the > window. > No, you never experience flickering in Gtk. Gtk is completely double buffered by itself If you want to know more, there is a nice overview: https://developer.gnome.org/gtk3/stable/chap-drawing-model.html But doing properly double or triple buffered video isn't that hard. > The hard part is integrating the display and event loop with GTK+. > That's not a problem, GStreamer integrates well with the Gtk main loop and there are video sinks for Gtk, like GtkSink and GstVideoOverlay Considering my issues here and in the other post I made about command > line arguments my solution for now is to just not use GTK+ in > preference of SDL2. This has the benefit of getting me very easy video > acceleration and better cross platform support. (The application links > in about 1/5th the time.) > Well SDL2 is a good library, sure. Choose what best suits your needs Hope it helps. Have a nice day! Luca 2018-08-01 17:44 GMT+02:00 R0b0t1 <r03...@gmail.com>: > On Wed, Aug 1, 2018 at 8:52 AM, Luca Bacci via gtk-list > <gtk-list@gnome.org> wrote: > > I should point out that the draw_func may be called by Gtk whenever it > > needs, > > The best is to have the timer callback change the "current" bitmap and > call > > gtk_widget_queue_draw_area(). > > Then on the drawing callback of the drawing area you just paint the > > "current" bitmap. > > > > This is what I first tried to do but could not find good information > on it. It seems I need to quickly create and destroy objects no matter > what I do which is why I sent this message. > > I can set an image control's GdkPixbuf but there seems to be no way to > change the data that a GdkPixbuf points to. It may also be necessary > to create another GtkImage to perform double buffering inside the > window. > > > On Wed, Aug 1, 2018 at 10:06 AM, Paul Davis <p...@linuxaudiosystems.com> > wrote: > > > > On Wed, Aug 1, 2018 at 9:44 AM, Luca Bacci via gtk-list < > gtk-list@gnome.org> > > wrote: > >> > >> I suggest you use GStreamer, you can build a video by pushing bitmap > >> frames and it does everything else for you. > >> > >> Otherwise, you can animate a DrawingArea. Set up a 60hz timer on your > own. > >> The timer callback simply calls > >> gtk_widget_queue_draw_area(). Then, on the draw_func of your drawingarea > >> you display the bitmaps, one after another. > >> That's the simplest solution but can have lower timing quality > > > > in GTK3, this is almost certainly not the best way to do this. You want > to > > use a frame timer based on the refresh/vblank cycle of the monitor. > > > > I suspect he realized and that is why he recommended just changing the > current bitmap. > > > The only reason I can find to not use GStreamer is that decoding is > already done for me. Putting the frames into a video and having that > displayed may lead to pointless copying of the video data. Pointless > copying is usually the biggest time sink. However this would mean the > video would be double/triple buffered properly upon display and would > use video acceleration. > > But doing properly double or triple buffered video isn't that hard. > The hard part is integrating the display and event loop with GTK+. > Considering my issues here and in the other post I made about command > line arguments my solution for now is to just not use GTK+ in > preference of SDL2. This has the benefit of getting me very easy video > acceleration and better cross platform support. (The application links > in about 1/5th the time.) > > Any pointers are still appreciated, of course. > > Cheers, > R0b0t1 > > > P.S. "GtkApplication is a class that handles many important aspects of > a GTK+ application in a convenient fashion, without enforcing a > one-size-fits-all application model." > > /me squints >
_______________________________________________ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
