summaryrefslogtreecommitdiff
path: root/gdk
Commit message (Collapse)AuthorAgeFilesLines
* Add gdk_frame_clock_begin/end_updating()Owen W. Taylor2013-02-185-25/+121
| | | | | | | | | | | | 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 unnecessary copy of GdkFrameClockIdlePrivateAlexander Larsson2013-02-181-2/+0
|
* win32: Fix buildAlexander Larsson2013-02-181-1/+0
| | | | | | gdkwindown-win32.c included windows.h directly rather than via gdkwin32.h which broke the build for me at least. Instead rely on it being included in gdkwin32.h and things work right.
* GdkWindowX11: the root window is not a toplevelOwen W. Taylor2013-02-161-8/+8
| | | | | | | | The macros we had for checking for toplevel windows were passing through the root window, which was not intentional and meant that for the root window WINDOW_IS_TOPLEVEL() returned TRUE but window->impl->toplevel was NULL, causing gdk_window_create_cairo_surface() to crash.
* GdkFrameClockIdle: remove timeouts in disposeOwen W. Taylor2013-02-151-7/+14
| | | | | When a frame clock is disposed, remove active timeouts; also get rid of the last traces of an unused GTimer.
* Update gdk.symbolsJasper St. Pierre2013-02-151-0/+20
|
* gdkframeclockidle: Don't expose sleep_source source funcsJasper St. Pierre2013-02-151-3/+3
|
* gdkframeclock: Fix doc commentsJasper St. Pierre2013-02-151-1/+1
|
* Don't compress motion events for different devicesOwen W. Taylor2013-02-141-0/+6
| | | | | | | | A switch of device may be significant for an application, so don't compress motion events if they are for different devices. This simple handling isn't sufficient if we have competing event streams from two different pointer events, but we don't expect this case to be common.
* Ignore window manager protocol messages for destroyed windowsOwen W. Taylor2013-02-141-7/+7
| | | | | If we get, for example, a _NET_WM_FRAME_DRAWN or _NET_WM_PING message on a destroyed window, then we should just ignore it.
* Small documentation fixes for frame synchronizationOwen W. Taylor2013-02-141-2/+2
| | | | Found by Benjamin Otte
* gdk_frame_clock_get_frame_time(): use gint64 for timeOwen W. Taylor2013-02-144-13/+13
|
* GdkFrameClock: update documentationOwen W. Taylor2013-02-142-103/+198
|
* GdkFrameTimings: add documentationOwen W. Taylor2013-02-142-0/+124
|
* GdkFrameClock: Clean up the public APIOwen W. Taylor2013-02-147-122/+24
| | | | | | | | | | | | | | | | * 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-148-280/+70
| | | | | | | | | 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-149-290/+170
| | | | | | 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-146-101/+154
| | | | | | | | | | | | 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.
* GdkWindow: make the frame clock an inherent property of the windowOwen W. Taylor2013-02-144-133/+92
| | | | | | | | Instead of making the frame clock a settable property of a window, make toplevel windows inherently have a frame clock when created (getting rid of the default frame clock.) We need to create or destroy frame clocks when reparenting a window to be a toplevel, or to not be a toplevel, but otherwise the frame clock for a window is immutable.
* Add gtk_widget_add_tick_callback(), remove GtkTimeline, etc.Owen W. Taylor2013-02-142-33/+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.
* GdkX11DeviceManagerXI2: handle focus events not on a known windowOwen W. Taylor2013-02-141-13/+16
| | | | | | If we get a focus event for a X window we don't recognize, just ignore it and avoid a g-critical when _gdk_device_manager_core_handle_focus() is called with a NULL window.
* Reimplement _NET_WM_SYNC_REQUEST inside X11 backendOwen W. Taylor2013-02-148-149/+31
| | | | | | | | Deprecate gdk_window_enable_synchronized_configure() and gdk_window_configure_done() and make them no-ops. Implement the handling of _NET_WM_SYNC_REQUEST in terms of the frame cycle - we know that all processing will be finished in the next frame cycle after the ConfigureNotify is received.
* Fix up for newer draft of wm-specOwen W. Taylor2013-02-143-16/+28
| | | | | * 64-bit quantities are consistently ordered low-32-bits / high-32-bits * data.l[4] in _NET_WM_SYNC_REQUEST indicates which counter to update
* Add gdk_frame_timings_get_predicted_presentation_time()Owen W. Taylor2013-02-149-19/+201
| | | | | | | | | | | | | | | | | | | | | 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 GDK_DEBUG=framesOwen W. Taylor2013-02-147-5/+184
| | | | | | Add a debug option to print out detailed statistics about each frame drawn. https://bugzilla.gnome.org/show_bug.cgi?id=685460
* GdkWindowX11: Communicate gdk_frame_timings_get_slept_before() to the compositorOwen W. Taylor2013-02-141-10/+23
| | | | | | | | | | | We want the compositor to do different things for frames where "slept before" is TRUE. Communicate to the compositor that frame is a no-delay frame (slept_before=FALSE) by ending the frame by increasing the counter value by 1, and that the frame is a normal frame (slept_before=TRUE) by increasing the counter value by 3. https://bugzilla.gnome.org/show_bug.cgi?id=685460
* Add gdk_frame_timings_get/set_slept_before()Owen W. Taylor2013-02-143-1/+85
| | | | | | | | | | Add functions that tell us whether the main loop slept before we drew a frame. Blocking with the frame clock frozen doesn't count as sleeping. We'll use this to advertise to the compositor whether we are drawing as fast as possible (and it should do the same) or timing frames carefully (and it should do the same.) https://bugzilla.gnome.org/show_bug.cgi?id=685460
* GdkFrameClockIdle: don't start the tiemout/idle when in a frameOwen W. Taylor2013-02-141-1/+8
| | | | | | | | Don't start the idle if we're in the middle of painting a frame - this will prevent us from getting the timing right when starting the idle after the frame. https://bugzilla.gnome.org/show_bug.cgi?id=685460
* Add GdkFrameHistory and GdkFrameTimings, handle _NET_WM_FRAME_TIMINGSOwen W. Taylor2013-02-1410-16/+575
| | | | | | | | | | | | | | | 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
* GdkWindowX11: Only start a frame when we emit damageOwen W. Taylor2013-02-142-8/+87
| | | | | | | | | | | | | | | | | Instead of communicating the start of a frame to the window manager as soon as we begin a frame, start a frame only when we know we've actually created damage to the contents of a window. (This uses cairo_set_mime_data() as a notification mechanism - a clever suggestion from Uli Schlachter.) The advantage of this is that we aren't forcing the compositor to do a frame cycle and send _NET_WM_FRAME_DRAWN - depending on how the compositor is structured that might either cause it to do extra work or it might send _NET_WM_FRAME_DRAWN early and upset frame timing. https://bugzilla.gnome.org/show_bug.cgi?id=685460
* GdkDisplay: handle multiple calls to _gdk_display_pause_events()Owen W. Taylor2013-02-144-10/+18
| | | | | | | | | Since events can be paused independently for each window during processing, make _gdk_display_pause_events() count how many times it is called and only unpause when unpause_events() is called the same number of times. https://bugzilla.gnome.org/show_bug.cgi?id=685460
* gdk_display_get_event: don't unqueue events from the windowing system when ↵Owen W. Taylor2013-02-142-7/+13
| | | | | | | | | | | | paused Unqueuing events from the windowing system when paused could result in weird reordering if event filters resulted in application-visible behavior. Since we now resume events when the frame clock is frozen, we now no longer count on low-level event handling running while event handling is paused. https://bugzilla.gnome.org/show_bug.cgi?id=685460
* GdkFrameClock: Reverse order of resume-events and afterpaintOwen W. Taylor2013-02-142-62/+58
| | | | | | | | | Keeping events paused after the end of a frame put us in a weird state where we had to process and queue events - so that we would get the message from the compositor - but not deliver them. Instead resume events before ending the frame. https://bugzilla.gnome.org/show_bug.cgi?id=685460
* Compress motion synchronized with the paint cycleOwen W. Taylor2013-02-148-37/+299
| | | | | | | | | | | | | | | | | | | 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-143-7/+67
| | | | | | | | | | | 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
* GdkFrameClockIdle: add throttling to 60fpsOwen W. Taylor2013-02-141-10/+36
| | | | | | | | | If the backend is throttling paints, then the frame clock will be frozen at the end of the frame. If not, then we need to add throttling, so wait until 16ms after the start of the frame before beginning the next frame. https://bugzilla.gnome.org/show_bug.cgi?id=685460
* GdkWindowX11: start off with an odd frame-counter valueOwen W. Taylor2013-02-141-13/+22
| | | | | | | | | | | | By starting with an odd frame counter value, we make the mapping and initial paint of the window an atomic operation, avoiding any visual artifacts from an unpainted window. Possible improvement: start the frame when doing gdk_window_show(), so that the same improvement occurs for windows that were previously shown and are being mapped again. https://bugzilla.gnome.org/show_bug.cgi?id=685460
* Freeze the update counter for unmapped windowsOwen W. Taylor2013-02-142-0/+9
| | | | | | | | | When a window is unmapped, freeze its frame clock. This avoids doing unnecessary work, but also means that we won't block waiting for _NET_WM_FRAME_DRAWN messages that will never be received since the frame ended while the window was withdrawn. https://bugzilla.gnome.org/show_bug.cgi?id=685460
* Use _NET_WM_FRAME_DRAWN to synchronize frame drawingOwen W. Taylor2013-02-143-2/+89
| | | | | | | | | | | | | As part of the extended _NET_WM_SYNC_REQUEST_COUNTER protocol, we get a _NET_WM_FRAME_DRAWN message for each frame we draw. Use this to synchronize the updates we are doing with the compositing manager's drawing, and ultimately with with display refresh. We now set the sync request counters on all windows, including override-redirect windows, since it is also useful to do synchronized, atomic updates for such windows. https://bugzilla.gnome.org/show_bug.cgi?id=685460
* Switch to an extended form of _NET_WM_SYNC_REQUEST_COUNTEROwen W. Taylor2013-02-143-21/+46
| | | | | | | | | | | | | | | | By exporting two XSync counters on a toplevel window, we subscribe to an extended form of the _NET_WM_SYNC_REQUEST_COUNTER protocol, where the window manager can initiate an atomic frame, as previously, but the application can also do so by incrementing the new counter to an odd value, and then to an even value to finish the frame. See: https://mail.gnome.org/archives/wm-spec-list/2011-October/msg00006.html The support for 64-bit integers that GLib requires is used to simplify the logic. https://bugzilla.gnome.org/show_bug.cgi?id=685460
* GdkFrameClock: add freeze/thawOwen W. Taylor2013-02-145-14/+110
| | | | | | | | | | | | | | 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-144-62/+86
| | | | | | | | | | 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-142-0/+22
| | | | | | | 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-148-52/+852
| | | | | | | | | | | | | 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
* GdkDisplayX11: Don't use substructure events in internal accountingOwen W. Taylor2013-02-141-51/+73
| | | | | | | | | | | | | We may receive events because SubstructureNotifyMask has been selected for the root window. (Most likely, this would occur because GTK+ is being used inside a window manager like Metacity or Mutter.) This can confuse various types of internal accounting, so detect such events and comprehensively ignore them for GDK's internal purposes. We still need to generate GDK events for these cases because you can select for substructure events with GDK_SUBSTRUCTURE_MASK. https://bugzilla.gnome.org/show_bug.cgi?id=685460
* wayland: Add support for output device removalRob Bradford2013-02-143-6/+24
| | | | | Since we only receive an object id for the removed object we must try and remove that from the list of devices based on that id.
* wayland: Add basic multiple output supportRob Bradford2013-02-143-3/+5
| | | | Store the wl_output pointer within the the GdkWaylandMonitor structure.
* settings: add a gtk-recent-files-enabled GtkSettingCosimo Cecchi2013-02-131-1/+2
| | | | | | | Backed by an XSetting, so g-s-d can set it according to the GSettings value. https://bugzilla.gnome.org/show_bug.cgi?id=693724
* wayland: Handle wl_output in GdkWaylandScreenJan Arne Petersen2013-02-133-71/+85
| | | | | Expose information about outputs in GdkScreen (gdk_screen_get_n_monitors and gdk_screen_get_monitor_*).
* wayland: skip pointer and keyboard events without a surfaceThomas Wood2013-02-121-0/+12
| | | | | | | Pointer and keyboard events can be received after the surface has been destroyed, in which case the surface will be NULL. https://bugzilla.gnome.org/show_bug.cgi?id=693338
View Lorry Controller Status