summaryrefslogtreecommitdiff
path: root/src
Commit message (Collapse)AuthorAgeFilesLines
* Include the pkgconfig-specified gdesktop-enums.hDaniel van Vugt2020-07-134-4/+4
| | | | | | | | | | | | | | | | | Instead of blindly hoping that `$INCLUDE` contains the parent directory of `gsettings-desktop-schemas`. Because `gsettings-desktop-schemas.pc` says: ``` Cflags: -I/SOME/DIRECTORY/gsettings-desktop-schemas ``` Which means to include the version that Meson has configured you need to drop the directory prefix and only `#include <gdesktop-enums.h>`. This fixes a build failure with local installs triggered by 775ec67a44 but it's also the right thing to do™. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1370
* Add tap-button-map and tap-and-drag-lock support to X11 and WaylandGiusy Margarita2020-07-104-0/+185
| | | | https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1319
* screen-cast/src: Remove follow up timeout source on disableJonas Ådahl2020-07-101-0/+2
| | | | | | | | | | | We failed to remove the timeout source when disabling, meaning that if a follow up was scheduled, and shortly after we disabled the source, the timeout would be invoked after the source was freed causing use-after-free bugs. Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1337 https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1365
* screen-cast/src: Use G_USEC_PER_SEC instead of 1000000Jonas Ådahl2020-07-081-2/+3
| | | | https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1361
* screen-cast/src: Record follow up frame after timeoutJonas Ådahl2020-07-085-5/+139
| | | | | | | | | | | | | | | | | | | | | | During animation or other things that cause multiple frames in a row being painted, we might skip recording frames if the max framerate is reached. Doing so means we might end up skipping the last frame in a series, ending with the last frame we sent was not the last one, making things appear to get stuck sometimes. Handle this by creating a timeout if we ever throttle, and at the time the timeout callback is triggered, make sure we eventually send an up to date frame. This is handle differently depending on the source type. A monitor source type reports 1x1 pixel damage on each view its monitor overlaps, while a window source type simply records a frame from the surface directly, except without recording a timestamp, so that timestamps always refer to when damage actually happened. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1361
* screen-cast/src: Fix signedness of timestamp fieldJonas Ådahl2020-07-081-1/+1
| | | | https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1361
* screen-cast/src: Make record functions return an error when failingJonas Ådahl2020-07-085-42/+53
| | | | | | | | | Now that we don't use the record function to early out depending on implicit state (don't record pixels if only cursor moved for example), let it simply report an error when it fails, as we should no longer ever return without pixels if nothing failed. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1361
* screen-cast: Let the reason for recording determine what to recordJonas Ådahl2020-07-085-29/+34
| | | | | | | | | | E.g. we'll have pointer movement that, if no painting is already scheduled, should only send new cursor metadata without any new pixel buffer. When this happens, tell next step to not record the pixels if this was the case, instead of having it rediscover this itself. Related: https://gitlab.gnome.org/GNOME/mutter/-/issues/1323 https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1361
* screen-cast/src: Add flag to maybe_record()Jonas Ådahl2020-07-085-9/+30
| | | | | | | Will later be used to make recording avoid recording actual pixel content if e.g. only the cursor moved. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1361
* screen-cast/window-stream-src: Fix indentationJonas Ådahl2020-07-081-2/+2
| | | | https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1361
* screen-cast-src: Make the two record vfuncs more similarly namedJonas Ådahl2020-07-085-33/+37
| | | | | | | | | | | | Both do more or less the same but with different methods - one puts pixels into a buffer using the CPU, the other puts pixels into a buffer using the GPU. However, they are behaving slightly different, which they shouldn't. Lets first address the misleading disconnect in naming, and later we'll make them behave more similarly. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1361
* background: Use NEAREST filtering when the texture is the monitor resolutionDaniel van Vugt2020-07-081-8/+15
| | | | | | | | | | | | | | | | | | | | | | | | | That was obviously always the intention, but it didn't work when the display was scaled. My 3840x2160 monitor with a 3840x2160 texture was being rendered with LINEAR filtering. It seems the `force_bilinear` flag was TRUE when it should be FALSE. Because a texture area that's an integer fraction of the texture resolution is still a perfect match when that integer is the monitor scale. We were also getting: `meta_actor_painting_untransformed (fb, W, H, W, H, NULL, NULL) == FALSE` when the display was scaled. Because the second W,H was not the real sampling resolution. So with both of those issues fixed we now get NEAREST filtering when the texture resolution matches the resolution it's physically being rendered at. Note: The background texture actually wasn't equal to the physical monitor resolution prior to January 2020 (76240e24f7). So it wasn't possible to do this before then. Since then however, the texture resolution is always equal to the physical monitor resolution. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1346
* tests/stage-view: Keep old stage views alive on hotplugFlorian Müllner2020-07-071-1/+5
| | | | | | | Otherwise we cannot reliably compare them to the new post-hotplug views. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1357
* window-actor/wayland: Remove custom get_paint_volume() vfuncRobert Mader2020-07-071-26/+0
| | | | | | | | | | | | | | It doesn't take all children - subsurfaces in this case - into account, thus creating glitches if subsurfaces extend outside of the toplevel surface. Further more it doesn't seem to serve any special purpose - it was added in f7315c9a36462, a pretty big commit, and no discussion was started about the code in question. So it was likely just overlooked in the review process. Closes https://gitlab.gnome.org/GNOME/mutter/-/issues/873 Closes https://gitlab.gnome.org/GNOME/mutter/-/issues/1316
* background-content: Mipmap background texture renderingDaniel van Vugt2020-07-071-4/+10
| | | | | | | | | | | | | | | | | | | gnome-shell displays workspace previews at one tenth scale. That's a few binary orders of magnitude so even using a LINEAR filter was resulting in visible jaggies. Now we apply mipmapping so they appear smooth. As an added bonus, the mipmaps used occupy roughly 1% the memory of the original image (0.1 x 0.1 = 0.01) so they actually fit into GPU/CPU caches now and rendering performance is improved. There's no need to traverse the original texture which at 4K resolution occupies 33MB, only a 331KB mipmap. In my case this reduces the render time for the overview by ~10%. Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/1416 https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1347
* x11: Look up reason for selection clear events from XFixesCarlos Garnacho2020-07-031-8/+1
| | | | | | | | | | | | If the event originates from a XSetSelectionOwner request, the event will contain a XFixesSetSelectionOwnerNotify subtype. The other subtypes (meant for the selection window being destroyed, and the client closing) are the situations where we mean to replace the selection. Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1268 https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1350
* wayland: Respond to frame callbacks also if a clone was paintedJonas Ådahl2020-07-021-3/+2
| | | | | | | | This will mean that a surface on one monitor, with e.g. a preview on another, will still get frame callbacks if the preview is painted, but itself being hidden. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
* tests/frame-clock: Check that destroy signal is emittedJonas Ådahl2020-07-021-0/+58
| | | | https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
* clutter/frame-clock: Add explicit destroy functionJonas Ådahl2020-07-022-11/+11
| | | | | | | | | The frame clock owner should be able to explicitly destroy (i.e. make defunct) a frame clock, e.g. when a stage view is destructed. This is so that other objects can keep reference to its without it being left around even after stopped being usable. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
* tests/stage-view: Test that timelime adapts to actor moving across viewsJonas Ådahl2020-07-021-0/+146
| | | | | | | The timeline should switch frame clock, and automatically continue on the new frame clock. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
* tests/stage-view: Test that actors pick the right frame clockJonas Ådahl2020-07-021-0/+83
| | | | https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
* tests/stage-view: Check that hotplugging reestablishes view listJonas Ådahl2020-07-021-0/+85
| | | | | | | | Currently there is a point in between hot plug, and when the stage view list is up to date. The check also tests for this behaviour; would this ever change, the test should be adapted to deal with this too. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
* tests/stage-view: Remove unnecessary warning supressionJonas Ådahl2020-07-021-16/+0
| | | | | | It doesn't occur anymore, so lets stop ignoring it. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
* clutter: Paint views with individual frame clocksJonas Ådahl2020-07-0220-355/+199
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Replace the default master clock with multiple frame clocks, each driving its own stage view. As each stage view represents one CRTC, this means we draw each CRTC with its own designated frame clock, disconnected from all the others. For example this means we when using the native backend will never need to wait for one monitor to vsync before painting another, so e.g. having a 144 Hz monitor next to a 60 Hz monitor, things including both Wayland and X11 applications and shell UI will be able to render at the corresponding monitor refresh rate. This also changes a warning about missed frames when sending _NETWM_FRAME_TIMINGS messages to a debug log entry, as it's expected that we'll start missing frames e.g. when a X11 window (via Xwayland) is exclusively within a stage view that was not painted, while another one was, still increasing the global frame clock. Addititonally, this also requires the X11 window actor to schedule timeouts for _NET_WM_FRAME_DRAWN/_NET_WM_FRAME_TIMINGS event emitting, if the actor wasn't on any stage views, as now we'll only get the frame callbacks on actors when they actually were painted, while in the past, we'd invoke that vfunc when anything was painted. Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/903 Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3 https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
* renderer: Use 'add_view()' when adding CRTC viewsJonas Ådahl2020-07-021-2/+1
| | | | | | | | This also changes the view construction path used by the renderer view to use the new 'add_view()' function, meaning we have a common entry point for views into the renderer, which will be useful later on. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
* renderer-x11-cm: Initialize screen stage view in one stepJonas Ådahl2020-07-023-34/+18
| | | | | | | | | Before we'd create the view in init(), then continue poking at it in realize(). Move all of the screen stage view initialization to realize(), as that's when we have all the dependent state available. This is possible since there is nothing needing it until realizing. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
* compositor: Use stage signals instead of clutter repaint callbacksJonas Ådahl2020-07-028-100/+73
| | | | | | | | | | | | The repaint callbacks are not tied to repaint, thus a bit misleading. What the functionality in the pre/post-paint callbacks here cares about is when actually painting; the non-painting related parts has already moved out to a *-update signal. This also renames the related MetaWindowActorClass vfuncs, to align with naming convention of the signals that it listens to. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
* wayland/compositor: Process frame callbacks on 'after-update'Jonas Ådahl2020-07-022-9/+8
| | | | | | | | | | | Instead of going via MetaCompositor to know about when we updated (confusingly named post-paint), use the new stage signal directly. Note that this doesn't change the time frame callbacks are dispatched; it's still not tied to actual painting even though it seemed so before given the function names. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
* compositor: Remove unused stage pointerJonas Ådahl2020-07-021-2/+0
| | | | https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
* cursor-renderer: Use 'after-paint' stage signal instead paint callbackJonas Ådahl2020-07-021-15/+23
| | | | | | | | The clutter "thread" repaint callback are not tied to painting, but indirectly to updating. What the cursor renderer cares about is when we actually painted, as this is related to the OpenGL fallback paths. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
* clutter/stage: Only emit "presented" on completion eventJonas Ådahl2020-07-022-29/+32
| | | | | | | | | We'd emit multiple "presented" signals per frame, one for "sync" and one for "completion". Only the latter were ever used, and removing the differentiation eases the avoidance of cogl onscreen framebuffer frame callback details leaking into clutter. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
* compositor: Remove 'pre-paint' signalJonas Ådahl2020-07-021-19/+1
| | | | | | It's not used; just use the vfunc directly. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
* surface-actor: Remove 'pre-paint' vfuncJonas Ådahl2020-07-026-19/+11
| | | | | | | | | The vfunc was not tied to "paint", but was used by MetaWindowActorX11 as part of the "update" mechanisms. In order to make that more clear, special case it in MetaWindowActorX11 by type checking the surface actor, handling the case without MetaSurfacActor abstraction. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
* compositor-x11: Move synchronization to before-updateJonas Ådahl2020-07-021-7/+35
| | | | | | | | | The synchronization must happen no matter the painting, as it in itself might result in reported damage, making the stage actually painted. Thus move it out of the "pre-paint" handler, to something explicitly not tied to the painting itself - ClutterStage::before-update. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
* laters: Use 'before-update' signal from stageJonas Ådahl2020-07-022-14/+22
| | | | | | | | | | | Instead of the 'pre-paint' signal on MetaCompositor, rely directly on the 'before-update' signal on the stage. A reason for this is that the callback should not only invoked in connection to painting, but updating in general. Currently the 'pre-paint' signal is emitted no matter whether there were any painting or not, but that's both misleading and will go away. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
* clutter: Remove multi thread mutexesJonas Ådahl2020-07-022-18/+1
| | | | | | | | | The mutexes was used by ClutterTexture's async upload and to match GDK's mutexes on X11. GDK's X11 connection does not share anything with Clutter's, we don't have the Gdk Clutter backend left, and we have already removed ClutterTexture, so lets remove these mutexes as well. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
* clutter: Include clutter-frame-clock.h from clutter.hJonas Ådahl2020-07-022-2/+1
| | | | | | So that it can be used by libmutter and gnome-shell. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
* clutter/frame-clock: Handle reschedule then dispatch results in idleJonas Ådahl2020-07-021-0/+63
| | | | | | | | | | | A frame clock dispatch doesn't necessarily result in a frame drawn, meaning we'll end up in the idle state. However, it may be the case that something still requires another frame, and will in that case have requested one to be scheduled. In order to not dead lock, try to reschedule directly if requested after dispatching, if we ended up in the idle state. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
* clutter/cogl: Take over global frame count responsibilityJonas Ådahl2020-07-025-40/+4
| | | | | | | | | The native backend had a plain counter, and the X11 backend used the CoglOnscreen of the screen; change it into a plain counter in ClutterStageCogl. This also moves the global frame count setting to the frame info constuctor. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
* cogl/onscreen: Let swap buffer caller create frame infoJonas Ådahl2020-07-022-9/+12
| | | | | | | | | | | | | | We currently have mutter set a global frame counter on the frame info in the native backend, but in order to do this from clutter, change the frame info construction from being implicitly done so when swapping buffers to having the caller create the frame info and passing that to the swap buffers call. While this commit doesn't introduce any other changes than the API, the intention is later to have the caller be able to pass it's own state (e.g. the global frame count) along with the frame info. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
* frame-clock: Pass frame info when notifying presentedJonas Ådahl2020-07-022-6/+30
| | | | | | | Instead of just the timestamp, pass the frame info struct we already, that also include refresh rate. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
* Gather all time unit conversion helpers in one placeJonas Ådahl2020-07-022-30/+0
| | | | | | | | | We had time unit conversion helpers (e.g. us2ms(), ns2us(), etc) in multiple places. Clean that up by moving them all to a common file. That file is clutter-private.h, as it's accessible by both from clutter/ and src/. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
* clutter/stage-view: Give a stage view a refresh rateJonas Ådahl2020-07-022-0/+5
| | | | | | | | | Currently unused, but it's intention is to use as a initial refresh rate for a with the stage view associated frame clock. It defaults to 60 Hz if nothing sets it, but the native backend sets it to the associated CRTCs current mode's refresh rate. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
* clutter/timeline: Deprecate timelines without an actor or frame clockJonas Ådahl2020-07-0213-32/+38
| | | | | | | | | Without an associated actor, or explicit frame clock set, in the future a timeline will not know how to progress, as there will be no singe frame clock to assume is the main one. Thus, deprecate the construction of timelines without either an actor or frame clock set. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
* laters: Use clutter_stage_schedule_update() instead of timelineJonas Ådahl2020-07-021-14/+10
| | | | | | | | | | | The MetaLater functionality needs to make sure an update is scheduled so that it can run its callbacks etc. This used a ClutterTimeline (which is an object more or less meant to drive animations markers, frames etc) just to keep the master frame clock running. We're moving away from a single master clock, so just schedule updates directly instead, with the newly exposed API. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
* screen-cast: Only check queued-redraw on the relevant viewsJonas Ådahl2020-07-022-6/+43
| | | | | | | | | | | | We'd check if there was any queued redraw on the stage, but this is inappropriate for two reasons: 1) A monitor and area screen cast source only cares about damage on a subset of the stage. 2) The global pending-redraw is going away when paint scheduling will be more view centric. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
* renderer: Add API to get a view list for a monitorJonas Ådahl2020-07-023-0/+84
| | | | | | | | Where renderer views correspond to CRTCs, this will result in a list of those views; otherwise (i.e. X11 CM), it'll result in a list containing the global view. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
* renderer-view: Keep track of what CRTC it is associated withJonas Ådahl2020-07-024-0/+29
| | | | | | | | For the nested and native backend, it'll point to the CRTC it was created for. On the X11 CM backend, it'll be NULL, as there is only a single global stage view. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
* clutter/stage-view: Pass a pointer to the stage during constuctionJonas Ådahl2020-07-022-0/+3
| | | | | | | This is so that stage views can interact with the stage they are views of. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
* tests/frame-clock: Add test that switches frame clock mid timelineJonas Ådahl2020-07-021-0/+86
| | | | https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
View Lorry Controller Status