summaryrefslogtreecommitdiff
path: root/gdk/gdkframeclock.c
Commit message (Collapse)AuthorAgeFilesLines
* Fix a few more doc issuesMatthias Clasen2013-02-251-0/+1
|
* Include GdkFrameClock in the docsMatthias Clasen2013-02-251-11/+11
| | | | | Make GdkFrameClock and GdkFrameTimings show up in the docs. A couple of minor doc fixes are also included.
* Add gdk_frame_clock_begin/end_updating()Owen W. Taylor2013-02-181-1/+43
| | | | | | | | | | | | 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: Fix doc commentsJasper St. Pierre2013-02-151-1/+1
|
* gdk_frame_clock_get_frame_time(): use gint64 for timeOwen W. Taylor2013-02-141-1/+1
|
* GdkFrameClock: update documentationOwen W. Taylor2013-02-141-96/+168
|
* GdkFrameClock: Clean up the public APIOwen W. Taylor2013-02-141-83/+4
| | | | | | | | | | | | | | | | * 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()
* GdkFrameTimings: strip down to a minimal public APIOwen W. Taylor2013-02-141-30/+21
| | | | | | | | | Since we're not exporting the ability to create your own frame clock for now, remove the setters for GdkFrameTimings fields. Also remove all setters and getters for fields that are more about implementation than about quantities that are meaningful to the applcation and just access the fields directly within GDK.
* Merge GdkFrameHistory into GdkFrameClockOwen W. Taylor2013-02-141-33/+150
| | | | | | 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.
* Change GdkFrameClock from an interface to a classOwen W. Taylor2013-02-141-25/+47
| | | | | | | | | | | | It's unlikely that anyone will want to have, say, a GtkWidget that also acts as a GdkFrameClock, so an abstract base class is as flexible as making GdkFrameClock an interface, but has advantages: - If we decide to never make implementing your own frame clock possible, we can remove the virtualization. - We can put functionality like history into the base class. - Avoids the oddity of a interface without a public interface VTable, which may cause problems for language bindings.
* Add gtk_widget_add_tick_callback(), remove GtkTimeline, etc.Owen W. Taylor2013-02-141-13/+0
| | | | | | | | | | | | | | | Add a very simple GtkWidget function for an "tick" callback, which is connected to the ::update signal of GdkFrameClock. Remove: - GtkTimeline. The consensus is that it is too complex. - GdkPaintClockTarget. In the rare cases where tick callbacks aren't sufficient, it's possible to track the paint clock with ::realize/::unrealize/::hierarchy-changed. GtkTimeline is kept using ::update directly to allow using a GtkTimeline with a paint clock but no widget.
* Add gdk_frame_timings_get_predicted_presentation_time()Owen W. Taylor2013-02-141-0/+73
| | | | | | | | | | | | | | | | | | | | | For an operation like synchronizing audio to video playback, we need to be able to predict the time that a frame will be presented. The details of this depend on the windowing system, so make the backend predict a presentation time for ::begin-frame and set it on the GdkFrameTimings. The timing algorithm of GdkFrameClockIdle is adjusted to give predictable presentation times for frames that are not throttled by the windowing system. Helper functions: gdk_frame_clock_get_current_frame_timings() gdk_frame_clock_get_refresh_info() are added for operations that would otherwise be needed multiple times in different locations. https://bugzilla.gnome.org/show_bug.cgi?id=685460
* Add GdkFrameHistory and GdkFrameTimings, handle _NET_WM_FRAME_TIMINGSOwen W. Taylor2013-02-141-0/+17
| | | | | | | | | | | | | | | In order to be able to track statistics about how well we are drawing, and in order to be able to do sophisticated things with frame timing like predicting per-frame latencies and synchronizing audio with video, we need to be able to track exactly when previous frames were drawn to the screen. Information about each frame is stored in a new GdkFrameTimings object. A new GdkFrameHistory object is added which keeps a queue of recent GdkFrameTimings (this is added to avoid further complicating the implementation of GdkFrameClock.) https://bugzilla.gnome.org/show_bug.cgi?id=685460
* Compress motion synchronized with the paint cycleOwen W. Taylor2013-02-141-0/+32
| | | | | | | | | | | | | | | | | | | When we have pending motion events, instead of delivering them directly, request the new FLUSH_EVENTS phase of the frame clock. This allows us to compress repeated motion events sent to the same window. In the FLUSH_EVENTS phase, which occur at priority GDK_PRIORITY_EVENTS + 1, we deliver any pending motion events then turn off event delivery until the end of the next frame. Turning off event delivery means that we'll reliably paint the compressed motion events even if more have arrived. Add a motion-compression test case which demonstrates behavior when an application takes too long handle motion events. It is unusable without this patch but behaves fine with the patch. https://bugzilla.gnome.org/show_bug.cgi?id=685460
* Add an UPDATE phase and GdkFrameClockTarget, use for GtkStyleContextOwen W. Taylor2013-02-141-0/+29
| | | | | | | | | | | Switch GtkStyleContext to using GdkFrameClock. To do this, add a new UPDATE phase to GdkFrameClock. Add a GdkFrameClockTarget interface with a single set_clock() method, and use this to deal with the fact that GtkWidget only has a frame clock when realized. https://bugzilla.gnome.org/show_bug.cgi?id=685460
* GdkFrameClock: add freeze/thawOwen W. Taylor2013-02-141-0/+17
| | | | | | | | | | | | | | Add the ability to freeze a frame clock, which pauses its operation, then thaw it again later to resume. Initially this is used to implement freezing updates when we are waiting for ConfigureNotify in response to changing the size of a toplevel. We need a per-window clock for this to work properly, so add that for the X11 backend. https://bugzilla.gnome.org/show_bug.cgi?id=685460
* GdkFrameClock: Make the phase explicit when requesting the frameOwen W. Taylor2013-02-141-33/+10
| | | | | | | | | | Instead of having gdk_frame_clock_request_frame() have gdk_frame_clock_request_phase() where we can say what phase we need. This allows us to know if we get a frame-request during layout whether it's just a request for drawing from the layout, or whether another layout phase is needed. https://bugzilla.gnome.org/show_bug.cgi?id=685460
* Use GdkFrameClock for relayoutOwen W. Taylor2013-02-141-0/+21
| | | | | | | Add a ::layout signal to GdkFrameClock and use it instead of an idle handler to drive the restyling and relayout of containers. https://bugzilla.gnome.org/show_bug.cgi?id=685460
* Add GdkFrameClockOwen W. Taylor2013-02-141-0/+287
Add an object GdkFrameClock that we associate with a GdkWindow. This tracks when the window needs to be repainted, and will also be used for other operations in the future like relayout and updating animations. Based on a patch from Havoc Pennington: https://mail.gnome.org/archives/gtk-devel-list/2010-October/msg00004.html https://bugzilla.gnome.org/show_bug.cgi?id=685460
View Lorry Controller Status