Mouse over a parent menu[bar] didn't work while the menu was open.
The fix was to correct the behaviour of pointer crossing events so that
the pointer appears to be only inside one window at a time.
See: http://tronche.com/gui/x/xlib/events/window-entry-exit/normal.html
We need this because it fixes menu activation. The menu activation code
looks at the time between events to determine if mouse clicks happen too
quickly.
Commit ff256956b2 introduced a frame_clock_events_paused
flag, but only ever set it to TRUE, instead of unsetting it when
events are resumed. This was leading to assertion failures in
_gdk_display_unpause_events().
If we are disconnecting from a frame clock that has paused event
processing and hasn't issued a resume yet make sure we resume the
events or they will stay blocked forever.
https://bugzilla.gnome.org/show_bug.cgi?id=742636
This function is given a barely setup GdkEvent, so the GdkDevice field
is still unset, causing warnings and misbehaviors when the position
is queried for it.
Given that the wintab GTK+ code seems to rely somewhat hard on the wintab
device managing the pointer cursor, query the pointer position from the
pointer itself.
https://bugzilla.gnome.org/show_bug.cgi?id=743330
The window used NULL as a parent window, which defaults internally to
using the root window of the default screen. But at the time wintab is
initialized, there is no default display/screen yet.
Fix this by retrieving this information from the given GdkDeviceManager,
so we don't have to wait for the display to be in place before
initialization.
https://bugzilla.gnome.org/show_bug.cgi?id=743330
In some layouts this inconsistency results in crashes in
gdk_gl_texture_from_surface() since it uses gdk_gl_context_get_window() but
the returned window is not the same as the one that is being painted so
"window->current_paint.surface" is NULL. I saw this problem when packing a
GdkGLArea into a GtkPaned.
https://bugzilla.gnome.org/show_bug.cgi?id=743146
- Specifically request GL version when creating context. Just specifying core
profile bit results in the requested version defaulting to 1.0 which causes
the core profile bit to be ignored and an arbitrary compatability context to be
returned.
- Fix GL painting by removing GL calls that have been depricated by the 3.2 core
profile.
- Additionally remove glInvalidateFramebuffer() call, it is not supported by 3.2
core.
https://bugzilla.gnome.org/show_bug.cgi?id=742953
The ICCCM says:
If the specified property is None, the requestor is an obsolete client.
Owners are encouraged to support these clients by using the specified
target atom as the property name to be used for the reply.
Lets do that, instead of crashing.
https://bugzilla.gnome.org/show_bug.cgi?id=740613
The previous fix for this issue in 732af31424 was incomplete.
It seems that posix_fallocate gives an ENODEV error when
called on an fd opened with shm_open on freebsd. Fix up
the error check to only trigger if we get ENOSPC.
https://bugzilla.gnome.org/show_bug.cgi?id=742980
If we use GDK_GL_PROFILE_3_2_CORE we are asking for a core profile
according to the GLX_ARB_create_context_profile extension. For that,
we pass the GLX_CONTEXT_CORE_PROFILE_BIT_ARB value for the
GLX_CONTEXT_PROFILE_MASK_ARB attribute.
The specification for the extension says that:
If the requested OpenGL version is less than 3.2,
GLX_CONTEXT_PROFILE_MASK_ARB is ignored and the functionality
of the context is determined solely by the requested version.
Since we're asking for a core profile, we assume a GL version greater
than or equal to 3.2; thus, we don't need to specify the
GLX_CONTEXT_MAJOR_VERSION_ARB or the GLX_CONTEXT_MINOR_VERSION_ARB
attributes, and instead just rely on whatever version GLX gives us.
This seems to work around a strange issue in Mesa; if we ask for a core
profile and any version > 3.0, we get broken rendering on any shared
context we create.
Sending backingScaleFactor to a NULL NSWindow will silently give the
value 0 for the scale factor, causing insidious divide-by-zero bugs down
the line. This checks if the NSWindow is NULL first, as seems to happen
throughout the rest of the file.
Note that I don't have a hi-DPI OS X machine to test this on, though.
https://bugzilla.gnome.org/show_bug.cgi?id=738338
We've observed hangs of mutter when it initializes GTK+, which
are caused by initializing GL, which in turn makes xwayland
call back into mutter. With this change, mutter should just
disable GL support in GDK, and things will work.
This adds support for OpenGL to the GDK Windows backend using the WGL API
calls, which enables programs that uses the GTK+ GLArea widgets to work on
Windows as well.
This also adds a simple utility function to query for the version of OpenGL
that is supported by the Windows system, like the one provided by the X11
backend.
Many thanks to Alex (and Emmanuele, who started the OpenGL integration in
GTK+) who offered advice and help along the way, as well as the X11 and
Wayland backend for this work to refer to and to model upon.
https://bugzilla.gnome.org/show_bug.cgi?id=740795
As the alignments, strides and image formats may be different across
platforms, make the texture upload a vfunc to allow backends to override
the GL commands for uploading textures for the software implementation for
gdk_gl_texture_from_surface(), if necessary.
Suggested by Alex to avoid copying non-trivial portions of code which would
then add maintainenace burden.
https://bugzilla.gnome.org/show_bug.cgi?id=740795
We can't combine multiple draws into one for the software fallback,
because each quad has a different texture. And we generally don't
want to make a larger single texture because then we would have
to upload more data.
The ICCCM says:
If the specified property is None , the requestor is an obsolete client.
Owners are encouraged to support these clients by using the specified
target atom as the property name to be used for the reply.
Lets do that, instead of crashing.
https://bugzilla.gnome.org/show_bug.cgi?id=740613
NULL-plus-something could be seen by the compiler to attempt to do
arithmetic with void *, which is a GCCism. Instead, do the math normally
and cast the results as a void *.
https://bugzilla.gnome.org/show_bug.cgi?id=740605
Use xdg_surface_set_window_geometry() to tell the compositor about the
shadow widths, this makes some gnome-shell/mutter features (edge resistance,
frames around windows in the overview, side maximization, ...) work alright
with GTK+.
In order to add this, some other places in gdkwindow-wayland had to gain
some knowledge about margins:
- xdg_surface_configure() now syncs the shadow after applying the state,
and gdk_wayland_window_set_shadow_width() possibly reconfigures the
window in order to preserve window geometry. This is necessary to keep
shadows in sync with state/geometry changes, as this does not happen
all at once.
- xdg_popups relative to an xdg_surface are shown relative to buffer
coordinates, so the left/top margins must be added there.
https://bugzilla.gnome.org/show_bug.cgi?id=736742
This requires us to use GL_TRIANGLES and six verts per quad instead
of four, which makes me think it might not be worth it on
well-optimized GL drivers. However, from talking to some driver
developers about it, the GL_TRIANGLES should be faster, since this
means that there's one giant contiguous buffer instead of many small
buffers.
If we were really rendering a lot of quads, I'd use an element buffer
and GL_PRIMITIVE_RESTART, but we're really not ever rendering that
many quads, and the setup cost for that would just be too annoying.
It's unused. At the same time, rename "begin_paint_region" to
"begin_paint". This will help us clean up how GDK painting works
in the future to allow more creative use of double-buffering.
This is needed in the edge case where the X11 backend rounded the actual
size, and the GL flipping really needs the correct window height to
do proper Y coordinate flipping.
https://bugzilla.gnome.org/show_bug.cgi?id=739750
This is required for the X backend GL integration. If the
window has a height that is not a multiple of the window scale
we can't properly do the y coordinate flipping that GL needs.
Other backends can ignore this and use the default implementation.
https://bugzilla.gnome.org/show_bug.cgi?id=739750
Rather than just rounding down the position *and* the size separately
we correctly calculate a rectangle in scaled window coords that fully
covers the real window size. This really only makes a difference
when the window size/position isn't a multiple of the window scale.
https://bugzilla.gnome.org/show_bug.cgi?id=739750
Keep track of the exact size of X windows in underlying pixels; we
generally use the scaled size instead, but to properly handle the GL
viewport for windows that aren't a multiple of window_scale,
we need to know the real size.
https://bugzilla.gnome.org/show_bug.cgi?id=739750
Although we specify a resize increment to try and get a size that is
a multiple of the window scale, maximization typically wins
over the resize increment, so the window might be odd sized.
Round *up* in this case, rather than down, since it's better to
truncate a line or two at the bottom and right of the window rather
than have a line or two that we don't know what to do with.
https://bugzilla.gnome.org/show_bug.cgi?id=739750
The current way of exposing GDK API that should be considered internal
to GTK+ is to append a 'libgtk_only' suffix to the function name; this
is not really safe.
GLib has been using a slightly different approach: a private table of
function pointers, and a macro that allows accessing the desired symbol
inside that vtable.
We can copy the approach, and deprecate the 'libgtk_only' symbols in
lieu of outright removal.
https://bugzilla.gnome.org/show_bug.cgi?id=739781
Instead of possibly calling wl_surface_commit() out of
GdkFrameClock::after-paint, tick the transient parent clock so ::after-paint
can be eventually run.
This ensures that the subsurface coordinates (considered part of the state
of the parent) aren't committed untimely, and guaranteed to be orderly with
the wl_subsurface-relative state.
This is a gtk-side fix for https://bugzilla.gnome.org/show_bug.cgi?id=738887
cairo_region_copy(NULL) will effectively return an empty region, as this
function is always meant to return valid memory. This however inverts the
meaning of the NULL region and results in entirely non-clickable windows.
We need to export the symbols so they can be used in the
inspector, but we don't really want to make this supported
public API, so keep them out of installed headers.
Store the cursor name on the cursor (rather than always using its type).
Use this when setting a cursor on a surface.
The mir server will fallback to using standard cursors from the cursor
theme if the name used is not one of those defined by mir, which is more
or less what we want to happen here in case of creating a cursor by
name.
If buffer age is undefined and the updated area is not the whole
window then we use bit-blits instead of swap-buffers to end the
frame.
This allows us to not repaint the entire window unnecessarily if
buffer_age is not supported, like e.g. with DRI2.
This moves the GDK_ALWAYS_USE_GL env var to GDK_GL=always.
It also changes GDK_DEBUG=nogl to GDK_GL=disable, as GDK_DEBUG
is really only about debug loggin.
It also adds some completely new flags:
software-draw-gl:
Always use software fallback for drawing gl content to a cairo_t.
This disables the fastpaths that exist for drawing directly to
a window and instead reads back the pixels into a cairo image
surface.
software-draw-surface:
Always use software fallback for drawing cairo surfaces onto a
gl-using window. This disables e.g. texture-from-pixmap on X11.
software-draw:
Enables both the above.
The Mir backend was checking for button mask changes to generate the appropriate
GDK event. When Mir generates a touch event it has no button mask. In this case
we'll just generate a primary button event.
This was unnecessarily creating a framebuffer in the texture case,
and it was not properly setting up a framebuffer with the texture
as source in the software fallback w/ texture source case.
Commit afd9709aff made us keep impl window
cairo surfaces around across changes of window scale. But the
window scale setter forgot to update the size and scale of the
surface. The effect of this was that toggling the window scale
from 1 to 2 in the inspector was not causing the window to draw
at twice the size, although the X window was made twice as big,
and input was scaled too. Fix this by updating the surface when
the window scale changes.
We need to use this in the code path where we make the context
non-current during destroy, because at that point the window
could be destroyed and gdk_window_get_display() would return
NULL.
This moves the code related to the frame sync code into
the is_attached check, which means we don't have to ever
run this when making non-window-paint contexts current.
This is a minior speed thing, but the main advantage
is that it makes making a non-paint context current
threadsafe.
This is not really needed. The gl context is totally tied to the
window it is created from by virtue of sharing the context with the
paint context of that window and that context always has the visual
of the window (which we already can get).
Also, all user visible contexts are essentially offscreen contexts, so
a visual doesn't make sense for them. They only use FBOs which have
whatever format that the users sets up.
To properly support multithreaded use we use a global GPrivate
to track the current context. Since we also don't need to track
the current context on the display we move gdk_display_destroy_gl_context
to GdkGLContext::discard.
We used to have a weak ref to the cairo surface and it was keep
alive by the references in the normal windows, but that reference
was removed by d48adf9cee, causing
us to constantly create and destroy the surface.
https://bugzilla.gnome.org/show_bug.cgi?id=738648
We want to create windows with the default visuals such that we then
have the right visual for GLX when we want to create the paint GL
context for the window.
For instance, (in bug 738670) the default rgba visual we picked for the
NVidia driver had an alpha size of 0 which gave us a BadMatch when later
trying to initialize a gl context on it with a alpha FBConfig.
Instead of just picking what the Xserver likes for the default, and just
picking the first rgba visual we now actually call into GLX to pick
an appropriate visual.
The visuals are typically sorted by some sort of "most useful first"
order. And picking the last one is likely to give us the weirdest
matching glx visual.
It is not possible to successfully build GTK+ on OS X 10.6 and below
since NSFullScreenWindowMask is only available starting with 10.7. Add
ifdef guards around setStyleMask: in order to allow it to build on
earlier OS X releases.
https://bugzilla.gnome.org/show_bug.cgi?id=737561
Commits 314b6abbe8 and eb9223c008 were ignoring
the fact that the code where found is set to 1 was modifying
col - which was an ok thing to do when that part of the code
was still breaking out of the loop, but it is no longer doing
that (since 2003 !). Fix things up by storing the final col
value in a separate variable and using that after the loop.
https://bugzilla.gnome.org/show_bug.cgi?id=738886
In various places, the broadway backend was just using
the default display and assumed that it is the broadway
display. That may not be the case in a multi-backend world,
so instead iterate over all displays and use the first
broadway display - still not perfect, but enough to survive
for now.
The current implementation of this script generate headers with \x-escaped
strings that can become too long (> 65535 characters) for Visual Studio
to consume, hence the build of broadwayd would break on Visual Studio.
This changes the script to instead format the string as an array of hex
characters, not unlike what GResource does, so that builds can continue as
normal on Visual Studio builds as well.
https://bugzilla.gnome.org/show_bug.cgi?id=739001
wayland doesn't strictly follow the XDG_RUNTIME_DIR spec by falling back
to another directory in case the runtime dir is not properly set.
When this variable is unset, wayland will log an error to us, which we
treat as fatal, aborting the entire program.
Skip ourselves all the trouble and don't try to bring up the wayland
backend when we know it will fail in this way.
https://bugzilla.gnome.org/show_bug.cgi?id=738873
This is mostly useful for fallback testing.
I suppose if people want finer grained GL ability testing, they can use
Mesa environment variables to tune things.
Its not really reasonable to handle failures to make_current, it
basically only happens if you pass invalid arguments to it, and
thats not something we trap on similar things on the X drawing side.
If GL is not supported that should be handled by the context creation
failing, and anything going wrong after that is essentially a critical
(or an async X error).
We make user facing gl contexts not attached to a surface if possible,
or attached to dummy surfaces. This means nothing can accidentally
read/write to the toplevel back buffer.
This adds the new type GdkGLContext that wraps an OpenGL context for a
particular native window. It also adds support for the gdk paint
machinery to use OpenGL to draw everything. As soon as anyone creates
a GL context for a native window we create a "paint context" for that
GdkWindow and switch to using GL for painting it.
This commit contains only an implementation for X11 (using GLX).
The way painting works is that all client gl contexts draw into
offscreen buffers rather than directly to the back buffer, and the
way something gets onto the window is by using gdk_cairo_draw_from_gl()
to draw part of that buffer onto the draw cairo context.
As a fallback (if we're doing redirected drawing or some effect like a
cairo_push_group()) we read back the gl buffer into memory and composite
using cairo. This means that GL rendering works in all cases, including
rendering to a PDF. However, this is not particularly fast.
In the *typical* case, where we're drawing directly to the window in
the regular paint loop we hit the fast path. The fast path uses opengl
to draw the buffer to the window back buffer, either by blitting or
texturing. Then we track the region that was drawn, and when the draw
ends we paint the normal cairo surface to the window (using
texture-from-pixmap in the X11 case, or texture from cairo image
otherwise) in the regions where there is no gl painted.
There are some complexities wrt layering of gl and cairo areas though:
* We track via gdk_window_mark_paint_from_clip() whenever gtk is
painting over a region we previously rendered with opengl
(flushed_region). This area (needs_blend_region) is blended
rather than copied at the end of the frame.
* If we're drawing a gl texture with alpha we first copy the current
cairo_surface inside the target region to the back buffer before
we blend over it.
These two operations allow us full stacking of transparent gl and cairo
regions.
This is a new function that gets called every time we're drawing
some area in the Gtk paint machinery. It is a no-op right now, but
it will be required later to keep track of what areas which
we previously rendered with GL was overwritten with cairo contents.
First of all we track the current update area during an
update in window->active_update_area. This will be used later
in end_paint to know the damaged area.
Secondly we keep track of old update areas for the last 2
frames. This will later allow us to reuse old framebuffer
contents in double or tripple buffer setups, only painting
what has changed since then.
Before 5e325c4, the default BitGravity was NorthWestGravity.
When static gravities were removed in 5e325c4, the BitGravity regressed
to the X11 default, Forget. Forget causes giant graphical glitches and
black flashes when resizing, especially in some environments that aren't
synchronized to a paint clock yet, like XWayland.
I'm assuming that the author assumed that the default of BitGravity was
NorthWestGravity, which is the default of WinGravity. Just go ahead and
fix this regression to make resizing look smooth again.
Currently writing wl_data_offer data into the fd is 1) synchronous, which
is noticeable when transferring large amounts of data, and 2) buggy, write()
error checking is done on the accumulator, breaking both the written data
accounting and error checking itself.
Fix both by making writes asynchonous through GOutputStream, the operation
is spun off and either finished, or cancelled if new data is stored in the
selection while the transfer is active.
The documentation explicitly states that 0 is an allowed value for using
the same scale as the window. This 0 value is also explicitly checked
down in the call chain and handled.
There is no need for a critical warning just because somebody
asked for a property that is not meaningful for the device.
Just document it as not useful for keyboard devices.
Parent is guaranteed to not be NULL. It can only ever be NULL for root
windows and root windows cannot be created with gdk_window_new() and
gdk_window_ensure_native() will exit early because they already are
native.
Also, both functions would crash a few lines below where parent gets
dereferenced.
Remove checks for NULL before g_free() and g_clear_object().
Merge check for NULL, freeing of pointer and its setting
to NULL by g_clear_pointer().
https://bugzilla.gnome.org/show_bug.cgi?id=733157
The warning may have had some value at some point, but if
people uninstall large icons just to make the warning go
away, it does more harm than good. So just remove it.
If we have a fullscreen window that covers a monitor, desktop
chrome is not relevant for placing of menus and other popups.
Therefore, return the full monitor geometry instead of the
workarea in this case.
https://bugzilla.gnome.org/show_bug.cgi?id=737251
If !owner_events, the pointer window has been usually set to NULL if
the pointer fell outside the grabbing widget, but it was not being
checked that the pointer_window is actually a child of the grab
window, in which case it should be obtained as if ungrabbed.
https://bugzilla.gnome.org/show_bug.cgi?id=735749
