Re: Display Raster Data?

[Luca Bacci <luca bacci982 gmail com>]

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 ()

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 <r030t1 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 <paul 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