| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
| |
Adapt all our tests and examples to the new initialization api.
|
| | |
|
| | |
|
| |
|
|
|
| |
When we connect to GtkWidget::draw, the signal handler should have
a return value. This fixes overdrawing client-side decorations.
|
| |
|
|
|
| |
Split the code for computing frame rate and latency into a separate file
so we can use it from multiple tests.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* 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()
|
| |
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
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
|
