This lets use use a scaled Xft/DPI for old apps while not
blowing up the size of scaled windows. Only apps supporting
Gdk/WindowScaleFactor should supprt Gdk/UnscaledDPI.
If you set GDK_SCALE=2 in the environment then all windows will be
scaled by 2. Its not an ideal solution as it doesn't handle
multi-monitors at different scales, and only affects gtk apps.
But it is a good starting points and will help a lot on HiDPI
laptops.
We track the list of outputs each window is on, and set the
scale to the largest scale value of the outputs. Any time the scale
changes we also emit a configure event.
We bind to the newer version of the wl_output which supports
the new done and scale events, and if we use this to get the
scale for each monitor (defaulting to 1 if not supported).
If a cairo_surface for a window has a device scale set we need
to respect this when creating a similar window. I.e. we want
to then automatically create a larger window which inherits
the scale from the original.
We also need to calculate a different device_offset if there
is a device_scale set.
-Don't include unistd.h unconditionally as it's not available in Visual
Studio, but include io.h where necessary.
-Avoid C99isms, and use _chsize_s in place of ftruncate when unistd.h is
not available (as in the case of Visual Studio)
Only look at "impl" windows in gdk_window_process_updates_with_mode()
since these are the only ones we care about. This avoids a lot of
unnecessary calls to g_list_copy() and g_object_ref().
We don't want to recurse into children that are clipped, as that is
wasted work. We handle this by moving the empty check to the top
of the function and only using the clipped region everywhere.
Move the call to gdk_x11_atom_to_xatom_for_display() outside of the
search loop in gdk_x11_screen_supports_net_wm_hint(). In my test case
(running Audacious for about a minute), this reduced the total number of
hash table lookups performed from 370,000 to 230,000.
https://bugzilla.gnome.org/show_bug.cgi?id=702913
and not on each keystroke, which for some IMs apparently caused a full
update on each keystroke, not just a check for changes. Patch from
Takuro Ashie, bug #698183.
window_type_hint_to_level(): applied patch from Paul Davis which moves
dialogs to NSFloatingWindowLevel. This is not quite the perfect
solution, but it's a pragmatic fix that makes apps which have both
window types much more usable, and prevents dialog from disappearing
under an application's main window.
(cherry picked from commit 59d49e1566)
Include config.h first so that _GDK_EXTERN may be defined once
and only once during the build, so that we do not get warnings/
errors for macro redefinition.
https://bugzilla.gnome.org/show_bug.cgi?id=701251
Include gdkwin32.h (which includes gdkprivate-win32.h and gdkwin32cursor.h
during the build of GDK-Win32) so that
gdk_win32_icon_to_pixbuf_libgtk_only() and
gdk_win32_pixbuf_to_hicon_libgtk_only() get exported, so that the GTK
DLL can link correctly.
Calling XIQueryPointer() on a slave device is going to trigger a
BadDevice X error. So in case we query a slave device state, ask the
master device instead.
https://bugzilla.gnome.org/show_bug.cgi?id=700233
Add missing check in gdk_x11_device_manager_xi2_get_window(), returning
NULL if no valid XI2Event* has been found. Calling code seems to be
prepared to handle NULLs coming from this function, so it should be
safe enough (e.g. check gdk_event_source_get_filter_window()).
https://bugzilla.gnome.org/show_bug.cgi?id=700465
We don't track the full clip for each window anymore, as this
is not useful when no windows are opaque. However, we still
need the full clip for the shape, so its calculated manually.
However, it was previously only recalculated when the clip changes
which doesn't correctly handle the case of a sibling geometry changing.
So, instead of doing this directly when geometry changes we just
set a bit in the toplevel whenever some window geometry changes, and
we then handle this in process_updates, updating the shape for all
native windows. This should be ok performance-wise because we don't
expect a lot of native children.
This is left over from an old effort to bundle gtk and its dependencies
into a Mac OS X Framework. The effort was more or less successful but
proved difficult to maintain and impractical to use because gtk programs
don't use the special Framework include syntax.
In the ancient X days you could have Xservers that had multiple active windows, like
one truecolor and one 8bit palette. Then most apps ran in 8bpp but a single window
would use truecolor. This is done by specifying different visuals for the windows.
To make this work we ensured that a window with a visual different from its parent
gets a native subwindow, so that X can tell the hardware to do its magic.
These days the only real time we get two different visual is when one is a rgba visual
and the other is not. So, the code to check this doesn't really do anything but
get in the way when someone accidentally manages to not get a rgba visual on
a child window (see bb7054b508). So, to avoid
such errors we just remove the "different visual than parent" check.
We need to send exposes for all native windows, even the ones
without an exposure mask set, because otherwise non-native
children of the native window with an exposure mask will
not be drawn.
This removes the typechecks in GDK_WINDOW_TYPE and GDK_WINDOW_DESTROYED. These
are only used internally in gdkwindow.c and gdkdisplay.c anyway, and these
functions check for typesafety of arguments on function entry.
This function returns all the children that has a specific user_data set.
This is used a lot in the new GtkWidget drawing code and doing
it this way is faster than getting every child and calling get_user_data
on each (which was a non-neglible part of the profiles). Additionally it
also allows use to use some kind of hashtable to make this operation even
faster if needed in the future.
This lets you register callbacks for when child widgets invalidate
areas of the window read it and/or change it.
For instance, this lets you do rendering effects and keeping offscreen
caches uptodate.
If we got the release event for the last buffer then we're
fine with writing directly to the window surface, as wayland
will not be looing at it. This saves us from allocating
and copying more data.
First of all, we now only do paints on native windows, as there is
really no reason anymore to do it for subwindows. Secondly, we
keep track of the paints even for GtkPaintable windows, but for
that case we don't create the offscreen surface, but rather
assume the windowing system does the backing store.
In the case where the layout phase queued a layout we don't
want to progress to the paint phase with invalid allocations, so
we loop the layout. This shouldn't normally happen, but it may
happen in some edge cases like if user/wm resizes clash with
natural window size changes from a gtk widget. This should not
generally loop though, so we detect this after 4 cycles and
print a warning.
This was detected because of an issue in GtkWindow where it
seems to incorrectly handle the case of a user interactive resize.
It seems gtk_window_move_resize() believes that configure_request_size_changed
changed due to hitting some corner case so it calls
gtk_widget_queue_resize_no_redraw(), marking the window as need_alloc
after the layout phase. This commit fixes the issue, but we should
also look into if we can fix that.
Now that all windows are non-opaque we can simplify the invalidation
a lot. There is no need to clip the invalidate area to child regions,
because we will always redraw everything under all the children.
We only have to handle native childen specially.
We now only do one expose event per native window, so there will
only be one begin/end_paint() call. This means all the work with
implicit paints to combine the paints on a single double buffer
surface is unnecessary, so we can just delete it.
We now consider non-native windows non-opaque, which means any invalid
area in a subwindow will also be invalid all the way up to the nearest
native windows. We take advantage of this by ignoring all expose events
on non-native windows (which typically means just the toplevel) and instead
propagating down the draw() calls to children directly via
gtk_container_propagate_draw.
This is nice as it means we always draw widgets the same way, and it
will let us do some interesting ways in the future.
We also clean up the GtkWidget opacity handling as we can now always
rely on the draing happening via cairo.
We can't really just draw by walking down the widget hierarchy, as
this doesn't get the clipping right (so e.g. widgets doing cairo_paint
may draw outside the expected gdkwindow subarea) nor does it let
us paint window backgrounds.
So, we now do multiple draws for each widget, once for each GdkWindow,
although we still do it on the same base cairo_t that we get for the
toplevel native window. The difference is only the clipping, the rendering
order, and which other widgets we propagate into.
We also collect all the windows of a widget so we can expose them inside
the same opacity group if needed.
NOTE: This change neuters gtk_widget_set_double_buffered for
widgets without native windows. Its impossible to disable
the double buffering in this model.
Since we dropped the move region optimization there is really no need
to try carefully keep track of opaque non-overlapped regions, as we
don't use this information to trigger the optimization anymore.
So, by assuming that all windows are non-opaque we can vastly simplify
the clip region stuff. First of all, we don't need clip_region_with_children,
as each window will need to draw under all children anyway. Secondly, we
don't remove overlapping sibling areas from clip_region, as these are
all non-opaque anyway and we need to draw under them
Finally, we don't need to track the layered region anymore as its
essentially unused. The few times something like it is needed we can
compute it explicitly.
For the case of native children of widgets we may cause a repaint
under native windows that are guaranteed to be opaque, but these
will be clipped by the native child anyway.
This basically neuters gdk_window_move_region, gdk_window_scroll
and gdk_window_move_resize, in that they now never copy any bits but
just invalidate the source and destination regions. This is a performance
loss, but the hope is that the simplifications it later allows will let
us recover this performance loss (which mainly affects scrolling).
Change the visibility handling to be the same way we do it in
GLib now. We pass -fvisibility=hidden to gcc and decorate public
functions with __attribute__((visibility("default"))).
This commit just does this for GDK, GTK+ will follow later.
Make all GDK_DEPRECATED and GDK_AVAILABLE macros use a
new _GDK_EXTERN macro. _GDK_EXTERN defaults to just 'extern'
but a subsequent commit will add visibility handling to it
while building GTK+.
