Commits on Source (21)
-
Jonas Ådahl authored
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/1351
d07335cd -
b1d45820
-
Jonas Ådahl authored
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/1351
92db8902 -
Jonas Ådahl authored
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. Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1323 https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1351
cf88d648 -
Jonas Ådahl authored
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/1351
2d899596 -
449fa7bf
-
Jonas Ådahl authored
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/1351
e8052f16 -
0c6ac287
-
Jonas Ådahl authored
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 (cherry picked from commit d67ba3ea)
1fd53c48 -
Rafael authoredef3dac70
-
Robert Mader authoredIt 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 f7315c9a, 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 (cherry picked from commit d722e59a)
4d8538d6 -
In the case of indirect rendering like the first frame to use mutter's background wallpaper: Texture_A -> FBO_B (Texture_B) -> FBO_C (screen) we would be trying to render the contents of both FBO_B and FBO_C in the same flush, before the contents of Texture_A had made it to FBO_B. So when FBO_C wants to use mipmaps of Texture_B they didn't exist yet and appeared all black. And the blackness would remain for subsequent frames as cogl has now decided the mipmaps of FBO_B are no longer "dirty" and don't need refreshing: FBO_B (Texture_B) (mipmaps_dirty==FALSE but black) -> FBO_C (screen) We must flush FBO_B before referencing Texture_B for use in rendering FBO_C. This only happens when Texture_A changes (e.g. when the user changes their background wallpaper) so there's no ongoing performance penalty from this flush. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1347 (cherry picked from commit 3a474556)
eae21f01 -
Daniel van Vugt authored
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 Origin: https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1347 (cherry picked from commit 32dbcd93)
3dab5120 -
Wine destroys its old selection window immediately before creating a new selection. This would trigger restoring the clipboard, which would overwrite the new selection with the old one. The selection window however can also be destroyed as part of the shutdown process of applications, such as Chromium for example. In those cases we want the clipboard to be restored after the selection window has been destroyed. Solve this by not immediately restoring the clipboard but instead using a timeout which can be canceled by any new selection owner, such as in the Wine case. Fixes https://gitlab.gnome.org/GNOME/mutter/-/issues/1338 https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1369 (cherry picked from commit e1c4e558)
299569c3 -
The memory selection source was only providing the "text/plain" or the "text/plain;charset=utf-8" mimetype, but not "STRING" or "UTF8_STRING", which some X11 clients, like wine, are looking for. This was breaking pasting from the clipboard in wine applications. Fix this by adding those targets when they are missing and the selection source provides the corresponding mimetypes. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1369 (cherry picked from commit c7d14244)
52a6b5df -
This is a potential leak discovered by static analysis, in fact if _COGL_GET_CONTEXT returns, the newly allocated struct isn't released. https://gitlab.gnome.org/GNOME/mutter/merge_requests/1195 (cherry picked from commit 645d596f)
14377144 -
If we get an error when fetching the window attributes, the group isn't ever free'd, so use an autopointer instead, releasing the stolen one. https://gitlab.gnome.org/GNOME/mutter/merge_requests/1195 (cherry picked from commit 1d75d5aa)
fdb76593 -
test_client_new might return early if conditions are not met, leaving some allocated data around without freeing it. Since we're not using the client before, there's no need to initialize it early and just initialize it when it's going to be returned. https://gitlab.gnome.org/GNOME/mutter/merge_requests/1195 (cherry picked from commit 506e0658)
eea81807 -
If clutter_init fails then we will not free state. https://gitlab.gnome.org/GNOME/mutter/merge_requests/1195 (cherry picked from commit d0ef660f)
e3b213f9 -
Florian Müllner authored
Update NEWS.
7d061a06 -
Simon McVittie authored84566747
