Owen W. Taylor [Wed, 14 Nov 2012 18:26:13 +0000 (13:26 -0500)]
GdkFrameClockIdle: don't start the tiemout/idle when in a frame
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.
Owen W. Taylor [Wed, 14 Nov 2012 17:49:06 +0000 (12:49 -0500)]
Add GdkFrameHistory and GdkFrameTimings, handle _NET_WM_FRAME_TIMINGS
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.)
Owen W. Taylor [Wed, 14 Nov 2012 17:23:41 +0000 (12:23 -0500)]
GdkWindowX11: Only start a frame when we emit damage
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.
Owen W. Taylor [Sun, 7 Oct 2012 18:13:56 +0000 (14:13 -0400)]
GdkDisplay: handle multiple calls to _gdk_display_pause_events()
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.
Owen W. Taylor [Sun, 7 Oct 2012 15:47:49 +0000 (11:47 -0400)]
gdk_display_get_event: don't unqueue events from the windowing system when 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.
Owen W. Taylor [Sun, 7 Oct 2012 15:42:45 +0000 (11:42 -0400)]
GdkFrameClock: Reverse order of resume-events and afterpaint
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.
Owen W. Taylor [Wed, 26 Sep 2012 14:28:06 +0000 (10:28 -0400)]
Compress motion synchronized with the paint cycle
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.
Owen W. Taylor [Tue, 18 Sep 2012 22:21:08 +0000 (18:21 -0400)]
Add a test of an animated resizing window
Add a test of a window with an animated size and contents. The
test accepts load factor command line argument to see how things
work as the drawing of the content requires more GPU resources.
Owen W. Taylor [Fri, 28 Sep 2012 16:38:14 +0000 (12:38 -0400)]
GtkTimeline: Wrap around the progress correctly when looping
When we have a looping animation for something like an angle,
we need to make sure that the distance we go past 1.0 becomes
the starting distance for the next frame. This prevents a
stutter at the loop position.
Owen W. Taylor [Thu, 27 Sep 2012 20:27:36 +0000 (16:27 -0400)]
Hook GtkTimeline up to GdkFrameClock
Use GdkFrameClock for the timing of GtkTimeline. This require the
user to provide either a GtkWidget or a GdkFrameClock when creating
the timeline. The default constructor now takes a GtkWidget. If you
want to create a GdkFrameClock without a widget, you need to use
g_object_new() and pass in a GdkFrameClock and GdkScreen.
Owen W. Taylor [Thu, 10 Nov 2011 23:01:44 +0000 (18:01 -0500)]
GtkTimeline: remove settable FPS
The frames-per-second for an animation should be controlled by how
fast we can process frames and the the frame-rate of the display; it's not
a meaningful app-settable property.
Owen W. Taylor [Fri, 27 Jul 2012 08:56:51 +0000 (04:56 -0400)]
Add back GtkTimeline
Add back the GtkTimeline code that previously made private and
then removed. It will be hooked up to GdkFrameClock. This commit
purely adds the old code back.
Owen W. Taylor [Wed, 26 Sep 2012 19:44:30 +0000 (15:44 -0400)]
Add an UPDATE phase and GdkFrameClockTarget, use for GtkStyleContext
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.
Owen W. Taylor [Thu, 27 Sep 2012 21:55:55 +0000 (17:55 -0400)]
GdkFrameClockIdle: add throttling to 60fps
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.
Owen W. Taylor [Thu, 4 Oct 2012 00:15:44 +0000 (20:15 -0400)]
GdkWindowX11: start off with an odd frame-counter value
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.
Owen W. Taylor [Thu, 4 Oct 2012 00:13:42 +0000 (20:13 -0400)]
Freeze the update counter for unmapped windows
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.
Owen W. Taylor [Tue, 18 Sep 2012 13:37:03 +0000 (09:37 -0400)]
Use _NET_WM_FRAME_DRAWN to synchronize frame drawing
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.
Owen W. Taylor [Tue, 18 Sep 2012 13:31:17 +0000 (09:31 -0400)]
Switch to an extended form of _NET_WM_SYNC_REQUEST_COUNTER
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.
Owen W. Taylor [Wed, 3 Oct 2012 23:38:40 +0000 (19:38 -0400)]
GdkFrameClock: Make the phase explicit when requesting the frame
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.
Owen W. Taylor [Wed, 3 Oct 2012 22:34:01 +0000 (18:34 -0400)]
Add GdkFrameClock
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.
Owen W. Taylor [Wed, 19 Sep 2012 02:13:06 +0000 (22:13 -0400)]
GdkDisplayX11: Don't use substructure events in internal accounting
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.
This is necessary in order to have async operations on it.
All the old copy/free functions keeps working, and g_boxed_copy on a GObject
also works, so this should be mostly compatible, but techncally its a minor
ABI break since the GType changes fundamental type. Changes like this has
happened before though, like with GVariant becomming its own fundamental
type.
filechooserbutton: In SELECT_FOLDER mode, consider an empty selection to mean current_folder
If the user didn't explicitly select anything, BUT the file chooser button has
a current_folder set, do the same as what GtkFileChooserDefault would do:
return the current folder as the selection.
This makes the tests in tests/filechooser pass!
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
filechooserbutton: Restore to an empty previous selection properly
If no file was originally selected in the GtkFileChooserButton, then its
internal dialog is brought up and cancelled, then we need to restore the
selection back to none. GtkFileChooser, though, doesn't like to
select a NULL file, so call _unselect_all() in that condition.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
filechooserbutton: Fix preserving the selection after cancelling the dialog
The button's underlying file chooser dialog should not be used to store the file selection
while the dialog is unmapped. Instead, the file chooser button now stores the
selection itself.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
filechooserbutton: Simplify the code to preserve the selection while the dialog is running
It used to fetch a possibly multiple selection from the GtkFileChooserDialog, and then
pick just the first item from the selection list. But since GtkFileChooserButton
operates in single-selection mode only, it can simply use gtk_file_chooser_get_file()
instead.
Also, the right way to reset the selection for GTK_FILE_CHOOSER_ACTION_SELECT_FOLDER
is with gtk_file_chooser_select_file(), not with _set_current_folder_file().
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
filechooser: Move some of the tests to GTestDataFunc
This code came from a home-grown testing mechanism, which didn't aggregate tests
into a test suite; it just ran them one by one. Here we move some of that machinery
to GTestDataFunc for more flexibility in running tests.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
This adds a way to get the gtk_widget_set_opacity liike behaviour
of retargeting GdkWindows and exposing every child in ::draw, without
actually having an alpha. This is needed if you're doing more complex things
such as cross fading of widgets.
We do this as a hack by using opacity values that round to 255 yet not
really 1.0 in order to avoid having some magical API call for this
mainly internal call.
Thomas Wood [Thu, 7 Feb 2013 11:59:31 +0000 (11:59 +0000)]
gdkwindow: don't use last_slave for the source device if it is NULL
Some backends do not have slave devices, which means last_slave may be
NULL. Use the current device as the source device if last_slave is NULL
when synthesizing a crossing event.
Simon Feltman [Fri, 8 Feb 2013 07:03:52 +0000 (23:03 -0800)]
gtkcellrenderertext: Sink floating entry before using as signal argument
Sink the GtkEntry assigned to the private structure of GtkCellRendererText
before signals containing it as an argument are sent out. This keeps
language bindings from sinking the reference and then destroying the entry
when the signal closure is finished.
When calling gtk_widget_draw() on the entry gtk_cairo_should_draw_window()
will return TRUE for all windows. This is used when rendering a widget to
somewhere other than the screen, and its now used for transparent widgets.
This caused the texthandle to always draw itself and terminate the draw
handler for the entry.
Instead we now only draw the markers when really visible, plus we return
FALSE to avoid stopping the entry drawing.
This adds gtk_widget_get/set_opacity, as well as a GtkWidget.opacity
property. Additionally it deprectates gtk_window_get/set_opacity and
removes the GtkWindow.opacity property (in preference for the new
identical inherited property from GtkWidget, which should be ABI/API
compat).
The implementation is using the new gdk_window_set_opacity child
window support for windowed widgets, and cairo_push/pop_group()
bracketing in gtk_widget_draw() for non-window widgets.
This replaces the previously hardcoded calls to gdk_window_set_user_data,
and also lets us track which windows are a part of a widget. Old code
should continue working as is, but new features that require the
windows may not work perfectly.
We need this for the transparent widget support to work, as we need
to specially mark the windows of child widgets.
gdkwindow: Allow gdk_window_set_opacity on non-native children
We now store the current opacity for all windows. For native windows
we just call into the native implementation whenever the opacity changes.
However, for non-native windows we implement opacity by pushing a
second implicit paint that "stacks" on the existing one, acting as
an opacity group while rendering the window and its children.
This works well in general, although any native child windows will of
course not be opaque. However, there is no way to implement
implicit paint flushing (i.e. draw the currently drawn double buffer
to the window in order to allow direct drawing to the window).
We can't flush in the stacked implicit paint case because there
is no way to get the right drawing behaviour when drawing directly
to the window. We *must* draw to the opacity group to get the right
behaviour.
We currently flush if:
* A widget disables double buffering
* You call move/resize/scroll a window and it has non-native children
during the expose handler
In case this happens we warn and flush the outermost group, so there may
be drawing errors.
Rob Bradford [Wed, 23 Jan 2013 16:55:59 +0000 (16:55 +0000)]
gdkwindow: Do not rely on a previous slave device when updating grab
_gdk_display_device_grab_update does not support passing in NULL for the
source device. If we don't have a slave device (saved in the pointer info)
then do not try and use that NULL pointer for the source_device.
This bug appeared in the Wayland backend where we (currently) only have master
devices exposed and as such no slave device is ever saved.
projects / ~andy / gtk / log