summaryrefslogtreecommitdiff
path: root/gdk
Commit message (Collapse)AuthorAgeFilesLines
* GdkRGBA: Fix typo in documentationTimm Bäder2020-07-171-1/+1
|
* array: Add a bunch of new featuresBenjamin Otte2020-07-161-16/+55
| | | | | | | | | | * GDK_ARRAY_BY_VALUE #define this to get GArray-like behavior * gdk_array_splice (v, 0, 0, NULL, 25) Adding items but passing NULL as the items will zero() them. * gdk_array_set_size() A nicer way to call gdk_array_splice() * constify getters
* array: Add null-terminationBenjamin Otte2020-07-161-7/+32
|
* Add GdkArrayBenjamin Otte2020-07-161-0/+219
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a scary idea where you #define a bunch of preprocessor values and then #include "gdkarrayimpl.c" and end up with a dynamic array for that data type. See https://en.wikipedia.org/wiki/X_Macro for what's going on. What are the advantages over using GArray or GPtrArray? * It's typesafe Because it works like C++ templates, we can use the actual type of the object instead of having to use gpointer. * It's one less indirection instead of 2 indirections via self->array->data, this array is embedded, so self->array is the actual data, and just one indirection away. This is pretty irrelevant in general, but can be very noticable in tight loops. * It's all inline Because the whole API is defined as static inline functions, the compiler has full access to everything and can (and does) optimize out unnecessary calls, thereby speeding up some operations quite significantly, when full optimizations are enabled. * It has more features In particular preallocation allows for avoiding malloc() calls, which can again speed up tight loops a lot. But there's also splice(), which is very useful when used with listmodels.
* Merge branch 'wip/fix-picom-crasher' into 'master'Matthias Clasen2020-07-153-5/+7
|\ | | | | | | | | | | | | x11: Don't set up frame sync fence on unsupported compositors Closes #2927 See merge request GNOME/gtk!2245
| * x11: Don't set up frame sync fence on unsupported compositorsRay Strode2020-07-143-5/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Not all compositors support _NET_WM_FRAME_DRAWN. In cases where the compositor doesn't support _NET_WM_FRAME_DRAWN we don't need to do all the fancy damage tracking and fence watching. Furthermore, if the compositor doesn't support _NET_WM_FRAME_DRAWN, it's possible that one frame will start before the previous frame has made it through the pipeline, leading to a blown assertion. This commit side-steps the unnecessary code and associated assertion when _NET_WM_FRAME_DRAWN isn't supported. Fixes: https://gitlab.gnome.org/GNOME/gtk/-/issues/2927
* | gdk/wayland: Add an API to inhibit and uninhibit idleEmmanuel Gil Peyrot2020-07-145-0/+48
|/ | | | | | | | | This uses the idle-inhibit protocol from wayland-protocols, to attach an inhibitor to the GdkSurface. The inhibit function can be called as many times as the user wants, but the uninhibit function MUST be called as many times to unset the idle inhibition. This has been tested on Sway.
* x11: Plug a memory leakMatthias Clasen2020-07-091-0/+2
| | | | Don't leak atoms when we're storing the clipboard.
* gdk/x11: Ignore regular crossing events while in implicit grabsCarlos Garnacho2020-07-091-2/+14
| | | | | | | | | | | | | | | | | | | If we create an implicit grab on a surface, leave the surface, and release the button, we would get 2 XI_Leave events, one with mode XINotifyNormal when the pointer leaves the surface, and another with mode XINotifyUngrab when the button is released. Meanwhile, the upper layers rely on crossing events being paired, and particularly in no crossing event being sent until the implicit grab is dismissed (either by releasing it, or via more pervasive grabs). Ignoring the set of XINotifyNormal events while an implicit grab is active adapts the X11 backend to this behavior. If the grab were released or taken away by another grab, a crossing event with one of the other XINotify*Grab/XINotify*Ungrab will be generated. Fixes: https://gitlab.gnome.org/GNOME/gtk/-/issues/2879
* gtk#767 add a way to change the application_id of a toplevel wayland GdkSurfaceCaolán McNamara2020-07-072-13/+37
| | | | | | | | | | | | so LibreOffice can reuse toplevels and get the right task icons references; https://gitlab.gnome.org/GNOME/gtk/-/issues/767 https://lists.freedesktop.org/archives/wayland-devel/2019-July/040704.html https://gitlab.freedesktop.org/wayland/wayland-protocols/commit/e0d6ad1d5e7e80321285a9b14ca3329289eb02e6 https://bugs.documentfoundation.org/show_bug.cgi?id=125934 https://bugzilla.redhat.com/show_bug.cgi?id=1334915 https://bugreports.qt.io/browse/QTBUG-77182
* x11: Avoid thawing surface until frame is drawnRay Strode2020-06-301-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since commit 972134abe48a4c9c7b6ad41b0723f30f4e7ae16b a frame getting drawn has three states (with the vendor nvidia driver at least): 1. drawn by gtk waiting on the GPU 2. drawn by GPU waiting on the compositor 3. drawn by compositor Those three states are encoded in two flags: frame_pending and frame_still_painting. frame_pending means step 1 is done, but step 2 and 3 are still in progress. frame_still_painting means step 2 is still in progress. After step 1 is finished the surface is frozen until step 3 is finished. When the compositor notifies gtk it's done with step 3, with a _NET_WM_FRAME_DRAWN client message, the toolkit thaws the surface to allow the next frame to proceed. The compositor sometimes sends gtk a _NET_WM_FRAME_DRAWN client message between steps 1 and 2. This message should be ignored because it's not a reply to the current frame. Unfortunately, gtk currently assumes if it gets a _NET_WM_FRAME_DRAWN client message while waiting for step 2 that it's actually at step 3, and proceeds to draw a new frame while the existing frame is still pending, leading to a blown assertion. This commit addresses the problem by ignoring _NET_WM_FRAME_DRAWN client messages from the compositor unless actually expecting one. Fixes: #2902
* x11: Handle window getting unmapped while frame still pendingRay Strode2020-06-301-10/+49
| | | | | | | | | | | | | | | | Since commit 972134abe48a4c9c7b6ad41b0723f30f4e7ae16b we now call glClientWaitSync for the vendor nvidia driver, to know when a frame is ready for the compositor to process. If a surface is hidden while a frame is still being rendered by the GPU, the surface will never produce the damage event the code relies on to trigger the call to glClientWaitSync. This leaves the fence dangling, and the next time the surface is shown, it will start a fresh frame and blow an assertion since the fence from the last frame is still hanging around. This commit ensures a frame gets fully wrapped up before hiding a surface.
* gdk: Better help for GDK_DEBUGMatthias Clasen2020-06-282-29/+128
| | | | | | | | Include docstrings and format the list of supported values better. Also, add the same warning we have for GTK_DEBUG when the environment variable is ignored.
* wayland: Respect GDK_DEBUG=default-settingsMatthias Clasen2020-06-281-0/+3
| | | | | | You can get this in other ways for Wayland (by setting GSETTINGS_BACKEND=memory), but it is better to be consistent across backends.
* gdk: Small documentation fixesMatthias Clasen2020-06-281-1/+1
| | | | Make sure gdk_event_get_seat shows up.
* docs: Remove ancient version informationMatthias Clasen2020-06-271-6/+4
| | | | We treat 4.0 as a new era.
* gdk: Drop gdk_device_get_last_event_surface()Carlos Garnacho2020-06-242-30/+0
| | | | | | This kind of transient state sets the expectative that events update devices, while it's more accurate to say that devices generate events. It does not make to expose this function anymore.
* gdk: Depend less on gdk_event_get_device()Carlos Garnacho2020-06-235-18/+14
| | | | For the most part, we are interested in seats here.
* gdk: Add gdk_event_get_seat()Carlos Garnacho2020-06-232-0/+19
| | | | | It currently fetches the seat from the event device, will be changed in future commits.
* gdk: Drop gdk_seat_get_logical_pointers()Carlos Garnacho2020-06-235-74/+0
| | | | | | Events come from hardware devices and are handled by controllers, there's no need to use logical pointers, nor to peek them. Drop this unused API.
* gdk: Drop GdkGrabOwnershipCarlos Garnacho2020-06-2311-104/+11
| | | | | We no longer expose such low level tweaks, this is essentially unused.
* gdk: Drop supports_multidevice APICarlos Garnacho2020-06-233-54/+0
| | | | | | Crossing events are now detached from widget state, all tricky consequences from getting multiple crossing events are now somewhat moot. Resort to sending all generated crossing events, and drop this barely (ever?) used API.
* gdk: Drop GDK_SOURCE_ERASERCarlos Garnacho2020-06-234-80/+36
| | | | All tools come from devices with GDK_SOURCE_PEN.
* x11: Ensure bound context is compatible with sync fenceRay Strode2020-06-221-7/+41
| | | | | | | | | | Commit a0f6ff101e781aaf0a931be6e22f2885f4f69e04 made sure that a context was bound before calling glClientWaitSync, but it doesn't check that the context shares objects with the context that created the fence. This commit does a little more validation before deciding the current context is good enough.
* x11: ensure some context is bound before calling glClientWaitSyncRay Strode2020-06-221-0/+8
| | | | | | | | | | | | | | Since commit 972134abe48a4c9c7b6ad41b0723f30f4e7ae16b we now call glClientWaitSync for the vendor nvidia driver, to know when a frame is ready for the compositor to process. glClientWaitSync can be called regardless of which context is currently bound, but if no context is bound at all, it returns 0 without doing anything. This commit checks for that edge case, and ensures a context gets made current in the event no context is already current, before calling glClientWaitSync.
* Merge branch 'keyval-to-uni-fix' into 'master'Matthias Clasen2020-06-221-13/+7
|\ | | | | | | | | gdk: Make gdk_keyval_to_unicode platform-independent See merge request GNOME/gtk!2132
| * gdk: Clarify the docs of gdk_keyval_to_unicodeMatthias Clasen2020-06-221-3/+7
| | | | | | | | | | | | Explicitly state that the conversion does not take locale into account, and point out GDK_KEY_KP_Decimal as a candidate for special-casing.
| * gdk: Make gdk_keyval_to_unicode platform-independentMatthias Clasen2020-06-221-10/+0
| | | | | | | | | | The result of gdk_keyval_to_unicode should not depend on the platform.
* | x11: be more verbose when glClientWaitSync behaves unexpectedtlyRay Strode2020-06-221-1/+1
|/ | | | | | | | | | | | | | | | | | | | | When given a 0 timeout, glClientWaitSync is only supposed to return one of three possible values: - GL_ALREADY_SIGNALED - fence fired - GL_WAIT_FAILED - there was an error - GL_TIMEOUT_EXPIRED - fence hasn't fired yet In addition, it can also return GL_CONDITION_SATISFIED if a non-zero timeout is passed, and the fence fires while waiting on the timeout. Since commit 972134abe48a4c9c7b6ad41b0723f30f4e7ae16b we now call glClientWaitSync (with a 0 timeout), but one user is reporting it's returning some value that's not one of the above four. This commit changes the g_assert to a g_error so we can see what value is getting returned. May help with https://gitlab.gnome.org/GNOME/gtk/-/issues/2858
* Merge branch 'gtk4-arb_fbo' into 'master'Matthias Clasen2020-06-201-7/+7
|\ | | | | | | | | Switch to GL_ARB_framebuffer_object See merge request GNOME/gtk!2079
| * Switch to GL_ARB_framebuffer_objectEmmanuel Gil Peyrot2020-06-121-7/+7
| | | | | | | | | | | | | | | | GTK 4.0 was currently using GL_EXT_framebuffer_object, which is deprecated as the ARB version has been merged into OpenGL 3.0 as well as OpenGL ES 2.0, and provides laxer requirements. This is a port of !2076 for 4.x.
* | Rename master and slave deviceEmmanuele Bassi2020-06-1824-513/+525
| | | | | | | | | | | | We already use the "logical/virtual" and "physical" names in the documentation, there's no reason to use loaded terms just because X11 uses them.
* | Fix minor typosYuri Chornoivan2020-06-189-11/+11
| |
* | gdk: Drop gdk_device_get_axis_value leftoversRico Tzschichholz2020-06-161-5/+0
| |
* | frame clock: fix schedulingYariv Barkan2020-06-151-20/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix scheduling of the frame clock when we don't receive "frame drawn" messages from the compositor. If we received "frame drawn" events recently, then the "smooth frame time" would be in sync with the vsync time. When we don't receive frame drawn events, the "smooth frame time" is simply incremented by constant multiples of the refresh interval. In both cases we can use this smooth time as the basis for scheduling the next clock cycle. By only using the "smooth frame time" as a basis we also benefit from more consistent scheduling cadence. If, for example, we got "frame drawn" events, then didn't receive them for a few frames, we would still be in sync when we start receiving these events again.
* | frame clock: adjust reported frame timeYariv Barkan2020-06-151-6/+115
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When an animation is started while the application is idle, that often happens as a result of some external event. This can be an input event, an expired timer, data arriving over the network etc. The result is that the first animation clock cycle could be scheduled at some random time, as opposed to follow up cycles which are usually scheduled right after a vsync. Since the frame time we report to the application is correlated to the time when the frame clock was scheduled to run, this can result in uneven times reported in the first few animation frames. In order to fix that, we measure the phase of the first clock cycle - i.e. the offset between the first cycle and the preceding vsync. Once we start receiving "frame drawn" signals, the cadence of the frame clock scheduling becomes tied to the vsync. In order to maintain the regularity of the reported frame times, we adjust subsequent reported frame times with the aforementioned phase.
* | Fix various compiler warnings with the 64bit mingw buildChristoph Reiter2020-06-145-10/+14
|/ | | | | | Use better matching format modifiers/specifiers, initialise some things which in theory wont be written to because of getters using g_return_if_fail(), a cast, and gsize as input for malloc because gsize!=glong on 64bit Windows.
* Merge branch 'scroll-compression' into 'master'Matthias Clasen2020-06-107-26/+171
|\ | | | | | | | | | | | | gdk: Compress scroll events Closes #2800 See merge request GNOME/gtk!2066
| * Address review commentsMatthias Clasen2020-06-091-5/+16
| | | | | | | | | | We were casting scroll events to motion events rather carelessly. Don't do that.
| * gdk: Add documentationMatthias Clasen2020-06-091-0/+6
| | | | | | | | Add some useful information about event history.
| * gdk: Rename gdk_motion_event_get_historyMatthias Clasen2020-06-092-68/+29
| | | | | | | | | | | | | | | | | | | | | | Scroll events can have history too, so make a getter that works for both. This drops the gdk_scroll_event_get_history getter that was added a few commits earlier, since we now store scroll history in the same way as motion history. Update the docs, and all callers.
| * gdk: Shrink GdkTimeCoordMatthias Clasen2020-06-091-6/+4
| | | | | | | | | | | | | | | | There is really no need to store 128 doubles as axes, ever. We can do just fine with 10. At the same time, add a GdkAxisFlags member, so we can interpret the values without having to go chasing the right device for this information.
| * gdk: Add scroll delta x/y as device axesMatthias Clasen2020-06-091-0/+8
| | | | | | | | | | | | They really are axes, and having them present in these enums lets use store delta values in GdkTimeCoord for keeping history.
| * Keep scroll historyMatthias Clasen2020-06-093-10/+80
| | | | | | | | | | | | Similar to how we keep motion history for compressed events, keep scroll history for compressed scroll events.
| * gdk: Compress scroll eventsMatthias Clasen2020-06-093-2/+93
| | | | | | | | | | | | | | | | | | | | Only return one accumulated scroll event per frame. Compress them by adding up the deltas. Still missing: a way to capture history, like we do for motion events. Fixes: #2800
* | gdk: Drop axis labelsMatthias Clasen2020-06-109-156/+47
| | | | | | | | | | | | This was only ever implemented on X11, and the labels here were atom names, so unlikely to be useful for anything interesting.
* | gdk: Drop gdk_device_set_axis_useMatthias Clasen2020-06-092-45/+0
| | | | | | | | | | If you need some axes changed, you can just flip the values when you receive them.
* | gdk: Drop gdk_device_get/set_keysMatthias Clasen2020-06-093-109/+0
| | | | | | | | | | This functionality was only ever half-implemented on X11, and is not useful enough to keep around.
* | x11: Stop setting device keysMatthias Clasen2020-06-091-7/+1
|/ | | | | This is very vestigial functionality, and basically unused.
* gdk: Drop gdk_device_get_historyMatthias Clasen2020-06-083-104/+0
| | | | This function is not implemented anywhere.
View Lorry Controller Status