summaryrefslogtreecommitdiff
path: root/tests/video-timer.c
Commit message (Collapse)AuthorAgeFilesLines
* Use gtk_window_set_child throughoutMatthias Clasen2020-05-041-1/+1
| | | | | Replace all uses of gtk_container_add on windows by gtk_window_set_child.
* tests: Add common_cflags to buildTimm Bäder2020-03-061-0/+3
| | | | | | And fix all the errors and warnings resulting from that See #2491
* window: Remove type argument from gtk_window_new()Benjamin Otte2020-02-141-1/+1
|
* Stop using gtk_main and gtk_main_quitMatthias Clasen2020-02-091-2/+15
| | | | Replace these calls with direct use of GMainContext api.
* Remove gtk_widget_show_allTimm Bäder2017-01-201-1/+1
|
* Update callersMatthias Clasen2017-01-191-2/+9
| | | | Adapt all our tests and examples to the new initialization api.
* tests: Use drawing area instead of draw signalBenjamin Otte2016-11-181-14/+15
|
* widget: Remove app-paintableTimm Bäder2016-10-311-1/+0
|
* animated-resizing, video-timer: Add missing return value from ::drawOwen W. Taylor2013-04-251-1/+3
| | | | | When we connect to GtkWidget::draw, the signal handler should have a return value. This fixes overdrawing client-side decorations.
* tests/animated-resizing: Split frame statistics out into a separate fileOwen W. Taylor2013-04-231-2/+2
| | | | | Split the code for computing frame rate and latency into a separate file so we can use it from multiple tests.
* Add gdk_frame_clock_begin/end_updating()Owen W. Taylor2013-02-181-3/+1
| | | | | | | | | | | | Add an API to start or stop continually updating the frame clock. This is a slight convenience for applcations and avoids the problem of getting one more frame run after an animation stops, but the primary motivation for this is because it looks like we might have to use timeBeginPeriod()/timeEndPeriod() on Windows to get reasonably accurate timing, and for that we'll need to know if there is an animation running. https://bugzilla.gnome.org/show_bug.cgi?id=693934
* GdkFrameClock: Clean up the public APIOwen W. Taylor2013-02-141-3/+3
| | | | | | | | | | | | | | | | * remove gdk_frame_clock_get_frame_time_val(); a convenience function that would rarely be used. * remove gdk_frame_clock_get_requested() and ::frame-requested signal; while we might want to eventually be able to track the requested phases for a clock, we don't have a current use case. * Make gdk_frame_clock_freeze/thaw() private: they are only used within GTK+ and have complex semantics. * Remove gdk_frame_clock_get_last_complete(). Another convenience function that I don't have a current use case for. * Rename: gdk_frame_clock_get_start() => gdk_frame_clock_get_history_start() gdk_frame_clocK_get_current_frame_timings() => gdk_frame_clock_get_timings()
* Merge GdkFrameHistory into GdkFrameClockOwen W. Taylor2013-02-141-6/+3
| | | | | | Now that GdkFrameClock is a class, not interface, there's no real advantage to splitting the frame history into an aggregate object, so directly merge it into GdkFrameClock.
* video-timer: add simple example of PLL-style clock adjustmentOwen W. Taylor2013-02-141-7/+83
| | | | | | | | | | | | | | | The first version of the video-timer simply played back the video according to the wall clock, and showed each frame at the neareste presentatin time. But an alternative strategy for playing back video is that if the frame-rate is an integer-divisor of the display refresh rate, or very close to that, is to change the playback speed to complete avoid frame drops and changes in latency. (This would require resampling audio if present.) Demonstrate this technique by adding a --pll option to the video-timer demo. https://bugzilla.gnome.org/show_bug.cgi?id=685460
* video-timer: add a test case for display at a constant frame rateOwen W. Taylor2013-02-141-0/+328
Add a test case that simulates the timing operaton that goes on when showing a constant frame rate stream like a video - each frame is shown at the VBlank interval that is closest to when it would ideally be timed. https://bugzilla.gnome.org/show_bug.cgi?id=685460