ekurzinger (Erik Kurzinger)
User

Projects

User does not belong to any projects.

Today

  • Clear sailing ahead.

Tomorrow

  • Clear sailing ahead.

Sunday

  • Clear sailing ahead.

User Details

User Since
Oct 15 2018, 5:53 PM (60 w, 3 d)
Availability
Available

Recent Activity

Oct 12 2019

ekurzinger added a comment to D23105: WIP: [platforms/x11] Cleanup GLX backend, revise compositing.

Sorry for the slow follow-up, but for whatever it's worth everything seems to work fine on a PRIME setup, even without D23881. No tearing, no hangs when rendering QtQuick pop-ups, and subjectively, latency when dragging windows, ect., feels about the same as before. So maybe the fall-back timer on NVIDIA hardware is good enough.

Oct 12 2019, 5:58 PM · KWin

Sep 11 2019

ekurzinger added a comment to D23881: Possible solution for scheduling repaints on NVIDIA.

Also, apart from the above two comments, any thoughts to how this relates to Roman's pending re-work of a lot of the GLX code https://phabricator.kde.org/D23105?

Sep 11 2019, 5:50 PM · KWin

Sep 4 2019

ekurzinger added a comment to D23105: WIP: [platforms/x11] Cleanup GLX backend, revise compositing.

Regarding the fallback to the composite timer when using the proprietary NVIDIA driver, while it doesn't really support anything equivalent to GLX_INTEL_swap_event, there is https://www.khronos.org/registry/OpenGL/extensions/NV/GLX_NV_delay_before_swap.txt which has the similar goal of reduced input latency. See the extension description for details, but essentially it allows the application to block until a specified time before the next swap. I'm not sure if that's exactly fits what KWin needs here, but maybe worth considering?.

Sep 4 2019, 8:23 PM · KWin

Jun 20 2019

ekurzinger updated the diff for D21899: [platforms/x11][5.12] Force QtQuick to Use Software Rendering on PRIME Systems.

Use QQuickWindow::setSceneGraphBackend instead of setting environment variable

Jun 20 2019, 8:52 PM · KWin

Jun 19 2019

ekurzinger added a comment to D21899: [platforms/x11][5.12] Force QtQuick to Use Software Rendering on PRIME Systems.

This might serve as a preferable alternative to reverting the tearing fix 22a441e071515e9c630f3bdac743c678052f88be for 5.12.

Jun 19 2019, 3:24 PM · KWin
ekurzinger requested review of D21899: [platforms/x11][5.12] Force QtQuick to Use Software Rendering on PRIME Systems.
Jun 19 2019, 3:20 PM · KWin
ekurzinger committed R108:0124b1ef191f: [platforms/X11] Disable VSync for QtQuick Windows (authored by ekurzinger).
[platforms/X11] Disable VSync for QtQuick Windows
Jun 19 2019, 3:07 PM
ekurzinger committed R108:56cd5f5557fb: [platforms/X11] Disable VSync for QtQuick Windows (authored by ekurzinger).
[platforms/X11] Disable VSync for QtQuick Windows
Jun 19 2019, 3:04 PM
ekurzinger closed D21808: [platforms/X11] Disable VSync for QtQuick Windows.
Jun 19 2019, 3:04 PM · KWin

Jun 17 2019

ekurzinger added a comment to D21808: [platforms/X11] Disable VSync for QtQuick Windows.

There was mention of switching QtQuick to use SW rendering on PRIME systems, would that be preferable to reverting the tearing fix?
I just learned that RandR will report a property named "PRIME Synchronization" for any affected outputs, so it should actually be easier than I originally thought to detect. Just need to call XRRListOutputProperies (or whatever the xcb equivalent is).
I can try to get a quick patch up for review if so.

Jun 17 2019, 9:48 PM · KWin
ekurzinger updated the diff for D21808: [platforms/X11] Disable VSync for QtQuick Windows.

alphabetized #include statements

Jun 17 2019, 6:11 PM · KWin

Jun 14 2019

ekurzinger updated the diff for D21808: [platforms/X11] Disable VSync for QtQuick Windows.

added brief explanation comment

Jun 14 2019, 11:19 PM · KWin
ekurzinger updated the test plan for D21808: [platforms/X11] Disable VSync for QtQuick Windows.
Jun 14 2019, 11:05 PM · KWin
ekurzinger retitled D21808: [platforms/X11] Disable VSync for QtQuick Windows from [platformx/X11] Disable VSync for QtQuick Windows to [platforms/X11] Disable VSync for QtQuick Windows.
Jun 14 2019, 8:47 PM · KWin
ekurzinger requested review of D21808: [platforms/X11] Disable VSync for QtQuick Windows.
Jun 14 2019, 8:38 PM · KWin

May 13 2019

ekurzinger added a comment to D19867: [X11] Force glXSwapBuffers to block with NVIDIA driver.

I posted a comment on the bug (shall we just move this discussion there going forward?) with a bit more explanation, but in summary David's patch seems to only prevent the hang the first time a QtQuick window is displayed. However, I think this might be more of a Qt issue that might be worth fixing upstream, although maybe it can be worked around in KWin as well. I'm not sure to what extend Qt and KDE development is coordinated?

May 13 2019, 8:59 PM · KWin

May 8 2019

ekurzinger added a comment to D19867: [X11] Force glXSwapBuffers to block with NVIDIA driver.

Alright, I think I see what the issue is. For context, on PRIME systems, since there isn't actually a display connected to the NVIDIA GPU, we rely on xf86-video-modeset, which drives the Intel GPU, to call to our driver after each vblank. However, it will actually only do so if there has been damage to the screen. So what I think we have here is QtQuick's thread waiting on this vblank signal before swapping buffers (since we set MaxFramesAllowed to 1), and KWin's main compositing thread waiting on the QtQuick thread. Since KWin isn't rendering to the screen while it waits, no damage occurs and hence this vblank signal is never sent. I think some timeout is what eventually gets things going again (after about 30 seconds). Does that make sense?

May 8 2019, 2:50 PM · KWin

May 6 2019

ekurzinger added a comment to D19867: [X11] Force glXSwapBuffers to block with NVIDIA driver.

Curious, sorry for overlooking PRIME systems in my testing. Since the QtQuick window would be redirected, MaxFramesAllowed=1 should have the effect of forcing glxSwapBuffers to wait until rendering for the previous frame has completed and the back buffer contents have been copied to the front buffer. I'm taking a look into this internally as well, having access to a debug NVIDIA driver might provide some more insight into what's going wrong. Will update with any progress, hopefully we can avoid having to revert the fix.

May 6 2019, 5:31 PM · KWin

Apr 15 2019

ekurzinger committed R108:c898f96df3e3: [platforms/drm] EGLStream DRM Backend Initial Implementation (authored by ekurzinger).
[platforms/drm] EGLStream DRM Backend Initial Implementation
Apr 15 2019, 2:32 PM
ekurzinger closed D18570: EGLStream DRM Backend Initial Implementation.
Apr 15 2019, 2:31 PM · KWin
ekurzinger committed R127:e208389cc68c: Implement wl_eglstream_controller Server Interface (authored by ekurzinger).
Implement wl_eglstream_controller Server Interface
Apr 15 2019, 2:26 PM
ekurzinger closed D18824: Implement wl_eglstream_controller Server Interface.
Apr 15 2019, 2:26 PM · Frameworks

Apr 12 2019

ekurzinger updated the diff for D18824: Implement wl_eglstream_controller Server Interface.

Changed the dynamic_cast in create() to static_cast. Since the Private is created in the constructor of EglStreamControllerInterface, it should be safe to assume it is of the correct type.
Also marked Private as Q_DECL_HIDDEN.

Apr 12 2019, 4:28 PM · Frameworks
ekurzinger updated the diff for D18824: Implement wl_eglstream_controller Server Interface.

Ok, now we will bail out early during create() if we fail to dynamically load the interface (before calling wl_global_create). The compositor can then use isValid() to check if whether creating the interface succeeded or not, it will also print a warning if it fails. Unfortunately, as Roman has pointed out, since Global::create is not virtual the compositor technically *could* still break things by calling the parent class method, but I'm not sure if it's worth changing that for just this one somewhat special case, especially considering that this will probably only ever actually be used by KWin's EGLStream backend anyway.

Apr 12 2019, 3:56 PM · Frameworks
ekurzinger added a comment to D18824: Implement wl_eglstream_controller Server Interface.

In the first revision the interface failed to create when the dynamically loaded library was not present (we said the class should always be created though). Now it just fails silently on bind. Why is it ok to fail silently on bind?

Apr 12 2019, 2:52 PM · Frameworks
ekurzinger updated the diff for D18824: Implement wl_eglstream_controller Server Interface.

Re-added protocol XML file to diff and corrected version in display.h

Apr 12 2019, 2:06 PM · Frameworks

Apr 11 2019

ekurzinger updated the diff for D18824: Implement wl_eglstream_controller Server Interface.

removed C-style casts

Apr 11 2019, 6:57 PM · Frameworks
ekurzinger added a comment to D18570: EGLStream DRM Backend Initial Implementation.

Awesome, just waiting on a final sign-off for https://phabricator.kde.org/D18824 and I'll get both checked in.

Apr 11 2019, 5:02 PM · KWin
ekurzinger committed R108:a1e8541b4947: [qpa] Don't specify EGL_SURFACE_TYPE when choosing EGLConfig (authored by ekurzinger).
[qpa] Don't specify EGL_SURFACE_TYPE when choosing EGLConfig
Apr 11 2019, 2:48 PM
ekurzinger closed D20455: [qpa] Don't specify EGL_SURFACE_TYPE when choosing EGLConfig.
Apr 11 2019, 2:48 PM · KWin

Apr 10 2019

ekurzinger added a dependency for D18570: EGLStream DRM Backend Initial Implementation: D20455: [qpa] Don't specify EGL_SURFACE_TYPE when choosing EGLConfig.
Apr 10 2019, 10:51 PM · KWin
ekurzinger added a dependent revision for D20455: [qpa] Don't specify EGL_SURFACE_TYPE when choosing EGLConfig: D18570: EGLStream DRM Backend Initial Implementation.
Apr 10 2019, 10:51 PM · KWin
ekurzinger requested review of D20455: [qpa] Don't specify EGL_SURFACE_TYPE when choosing EGLConfig.
Apr 10 2019, 10:50 PM · KWin

Mar 22 2019

ekurzinger added a comment to D18570: EGLStream DRM Backend Initial Implementation.

My blur's are missing, and I get a crash when the internal QPA creates a new GL surface over internal QOpenGLFramebufferObjects.
You'll see when you press alt+tab and it's set to show a dialog (https://phabricator.kde.org/P313)

Mar 22 2019, 10:48 PM · KWin

Mar 20 2019

ekurzinger committed R108:22a441e07151: [platforms/x11] Force glXSwapBuffers to block with NVIDIA driver (authored by ekurzinger).
[platforms/x11] Force glXSwapBuffers to block with NVIDIA driver
Mar 20 2019, 4:57 PM
ekurzinger closed D19867: [X11] Force glXSwapBuffers to block with NVIDIA driver.
Mar 20 2019, 4:57 PM · KWin

Mar 19 2019

ekurzinger committed R108:d9c79e36274c: [platforms/drm] Fix software cursors with drm backend (authored by ekurzinger).
[platforms/drm] Fix software cursors with drm backend
Mar 19 2019, 7:52 PM
ekurzinger closed D18376: Fix software cursors with drm backend.
Mar 19 2019, 7:52 PM · KWin
ekurzinger added a comment to D18570: EGLStream DRM Backend Initial Implementation.

What's our plan for the EGL_TEXTURE_FORMAT issue? Simply to implicitly depend on the new driver?

I'm hoping this bug, along with the tool-tip issue, might be considered minor enough to not warrant holding up the show until we can get fixes out (which should be soon). The desktop is still essentially usable with them present, right? And the backend already depends on a fairly recent version of the driver with support for all of the required EGL stream features (some of which are fairly new).

Mar 19 2019, 3:00 PM · KWin

Mar 18 2019

ekurzinger requested review of D19867: [X11] Force glXSwapBuffers to block with NVIDIA driver.
Mar 18 2019, 9:41 PM · KWin

Mar 13 2019

ekurzinger added a comment to D18376: Fix software cursors with drm backend.

Instead of emitting cursorChanged from DrmBackend, modify SceneOpenGL to connect Platform::cursorChanged as opposed to Cursor::cursorChanged to the cursor texture update function.

Where does the platform emit cursorChanged?
On wayland the only place I can see that emits Platform::cursorChanged is connected to CursorImage::changed

Mar 13 2019, 9:23 PM · KWin

Mar 12 2019

ekurzinger updated the diff for D18570: EGLStream DRM Backend Initial Implementation.
Mar 12 2019, 11:32 PM · KWin
ekurzinger updated the diff for D18570: EGLStream DRM Backend Initial Implementation.

Sorry for the delay, but the new backend now integrates into the atomic modesetting path of DrmOutput::present eliminating the need to expose the internal pageFlipPending flag and is a bit cleaner in general, I think. It leverages the existing code for modesets (which are now actually working correctly), however page flips are still performed through EGL. This necessitated adding an early return from DrmOutput::presentAtomically as well as not registering the flip event when using the EGLStream backend. I tried to make this as minimally-invasive as I could, and since there's already a fair amount of coupling between DrmOutput and DrmBackend hopefully a little bit more isn't the end of the world. Modesets use an empty dumb buffer, which is the same strategy that Mutter and Weston's EGLStream backends employ.

Mar 12 2019, 8:22 PM · KWin

Feb 22 2019

ekurzinger added a comment to D18570: EGLStream DRM Backend Initial Implementation.

And I was not talking in my review comments about superficial stuff,

We're just talking about the use of DrmOutput::present, right?
We could make a fake DrmBuffer instance round that doesn't do anything - and add some property in DrmBuffer to indicate whether we perform the relevant DRM calls or not. Would you prefer that?

@erik
One difference missing is that when we change modes we delay it till the DrmOutput::presentLegacy and then call drmModeSetCrtc with the pending buffer handle.
Right now as far as I can see any type of mode switching is missing.

Feb 22 2019, 5:58 PM · KWin

Feb 20 2019

ekurzinger added a comment to D18570: EGLStream DRM Backend Initial Implementation.

Is that in the KWayland master branch? In the file I'm looking at buffer_interface.cpp:152 is in the middle of a switch statement in the constructor.

Feb 20 2019, 11:30 PM · KWin

Feb 19 2019

ekurzinger updated the diff for D18570: EGLStream DRM Backend Initial Implementation.

Updated diff against HEAD

Feb 19 2019, 8:25 PM · KWin

Feb 14 2019

ekurzinger added a comment to D18570: EGLStream DRM Backend Initial Implementation.

First off: a driver not supporting Atomic Mode Setting is nothing modern. Does Nvidia has a plan to improve in this regard?

I'm really not happy, that the DrmOutput::present is not run and we have to export these internals from DrmOutput to the EglStreamBackend, which replaces the flip with an EGL function call. Why does the Nvidia driver not integrate with the libdrm API in regards to page flipping? It should be possible to at least offer a wrapper around it or not?

Feb 14 2019, 10:51 PM · KWin
ekurzinger updated the diff for D18570: EGLStream DRM Backend Initial Implementation.
  • Fixed style issues in drm_backend.cpp / drm_output.h
  • Switched surface -> texture map to use SurfaceInterface pointers instead of wl_resource pointers
  • Moved eglQueryWaylandBufferWL to egl_stream_backend.cpp
  • Added support for receiving stream attributes from EglStreamControllerInterface (currently unused by the driver, but good for future proofness).
Feb 14 2019, 8:11 PM · KWin
ekurzinger updated the diff for D18824: Implement wl_eglstream_controller Server Interface.

Thanks for taking a look, Roman. I've addressed your style suggestions and added support for passing stream attributes to the compositor. I had ignored these initially since the driver doesn't actually use this (fairly new) feature of the extension right now, but it probably is best to support it for future-proofness.

Feb 14 2019, 7:28 PM · Frameworks

Feb 12 2019

ekurzinger added a comment to D18570: EGLStream DRM Backend Initial Implementation.

Oh yeah, I've seen similar backtraces to that as well, actually. I think it's because QT is trying to share between an OpenGL context and an OpenGLES context. I don't think it's related to the compositor, though. It also occurs on GNOME and the weston eglstream port. I'm not sure if it's a QT bug or NVIDIA driver bug but I'll look into it a bit more as well.

Feb 12 2019, 12:40 AM · KWin

Feb 11 2019

ekurzinger added a comment to D18570: EGLStream DRM Backend Initial Implementation.
Feb 11 2019, 9:48 PM · KWin

Feb 8 2019

ekurzinger updated the diff for D18570: EGLStream DRM Backend Initial Implementation.

Use a KWayland wrapper around wayland-eglstream-controller instead of binding the interface from KWin. This avoids having to link against Wayland libraries. Depends on revision https://phabricator.kde.org/D18824 implementing the required KWayland class.

Feb 8 2019, 10:53 PM · KWin

Feb 7 2019

ekurzinger added a dependent revision for D18376: Fix software cursors with drm backend: D18570: EGLStream DRM Backend Initial Implementation.
Feb 7 2019, 11:32 PM · KWin
ekurzinger added dependencies for D18570: EGLStream DRM Backend Initial Implementation: D18824: Implement wl_eglstream_controller Server Interface, D18376: Fix software cursors with drm backend.
Feb 7 2019, 11:32 PM · KWin
ekurzinger added a dependent revision for D18824: Implement wl_eglstream_controller Server Interface: D18570: EGLStream DRM Backend Initial Implementation.
Feb 7 2019, 11:32 PM · Frameworks
ekurzinger removed a dependency for D18824: Implement wl_eglstream_controller Server Interface: D18570: EGLStream DRM Backend Initial Implementation.
Feb 7 2019, 11:32 PM · Frameworks
ekurzinger removed a dependency for D18376: Fix software cursors with drm backend: D18570: EGLStream DRM Backend Initial Implementation.
Feb 7 2019, 11:32 PM · KWin
ekurzinger removed dependent revisions for D18570: EGLStream DRM Backend Initial Implementation: D18376: Fix software cursors with drm backend, D18824: Implement wl_eglstream_controller Server Interface.
Feb 7 2019, 11:32 PM · KWin
ekurzinger added dependent revisions for D18570: EGLStream DRM Backend Initial Implementation: D18824: Implement wl_eglstream_controller Server Interface, D18376: Fix software cursors with drm backend.
Feb 7 2019, 10:31 PM · KWin
ekurzinger added a dependency for D18824: Implement wl_eglstream_controller Server Interface: D18570: EGLStream DRM Backend Initial Implementation.
Feb 7 2019, 10:31 PM · Frameworks
ekurzinger added a dependency for D18376: Fix software cursors with drm backend: D18570: EGLStream DRM Backend Initial Implementation.
Feb 7 2019, 10:31 PM · KWin
ekurzinger requested review of D18824: Implement wl_eglstream_controller Server Interface.
Feb 7 2019, 7:11 PM · Frameworks

Jan 31 2019

ekurzinger added inline comments to D18570: EGLStream DRM Backend Initial Implementation.
Jan 31 2019, 9:06 PM · KWin
ekurzinger updated the diff for D18570: EGLStream DRM Backend Initial Implementation.

Replaced dlopen / dlsym with QLibrary::resolve to avoid having to link against dl
Fixed a few more style issues
Added KWIN_BUILD_EGL_STREAM_BACKEND CMake option to control whether the new backend is built (defaults to ON).
Changed the name of the environment variable to KWIN_DRM_USE_EGL_STREAMS (instead of EGLDEVICE) to be a bit more consistent.

Jan 31 2019, 9:03 PM · KWin
ekurzinger added inline comments to D18570: EGLStream DRM Backend Initial Implementation.
Jan 31 2019, 7:44 PM · KWin

Jan 30 2019

ekurzinger updated the diff for D18376: Fix software cursors with drm backend.

Instead of emitting cursorChanged from DrmBackend, modify SceneOpenGL to connect Platform::cursorChanged as opposed to Cursor::cursorChanged to the cursor texture update function.

Jan 30 2019, 6:36 PM · KWin
ekurzinger updated the diff for D18570: EGLStream DRM Backend Initial Implementation.
Jan 30 2019, 6:14 PM · KWin

Jan 29 2019

ekurzinger closed D18307: Call frameRendered for undamaged Wayland surfaces.
Jan 29 2019, 9:42 PM · KWin
ekurzinger updated the diff for D18570: EGLStream DRM Backend Initial Implementation.

Added context to the diff and fixed style issues, (thanks the feedback)

Jan 29 2019, 9:39 PM · KWin
ekurzinger added 1 commit(s) for D18307: Call frameRendered for undamaged Wayland surfaces: R108:f294e7a03567: Call frameRendered for undamaged Wayland surfaces.
Jan 29 2019, 9:20 PM · KWin
ekurzinger added an edge to R108:f294e7a03567: Call frameRendered for undamaged Wayland surfaces: D18307: Call frameRendered for undamaged Wayland surfaces.
Jan 29 2019, 9:20 PM
ekurzinger added inline comments to D18570: EGLStream DRM Backend Initial Implementation.
Jan 29 2019, 9:14 PM · KWin
ekurzinger moved T10362: Call frameRendered for undamaged Wayland surfaces from Under Review to Done on the KWin board.
Jan 29 2019, 8:41 PM · KWin
ekurzinger committed R108:f294e7a03567: Call frameRendered for undamaged Wayland surfaces (authored by ekurzinger).
Call frameRendered for undamaged Wayland surfaces
Jan 29 2019, 8:40 PM
ekurzinger added a comment to D18570: EGLStream DRM Backend Initial Implementation.
In D18570#401368, @hein wrote:

If I blacklist the kscreen2 kded module, I can get the session to start (otherwise it crashes during the splash). However, all surfaces (e.g. the panel or krunner) don't react to mouse clicks and seem frozen-ish.

BTW, while playing around with this I noticed that kwin_wayland doesn't work in windowed mode on X when run on nVidia EGL, due to the driver not implementing GL_OES_EGL_image.

Jan 29 2019, 4:32 PM · KWin

Jan 27 2019

ekurzinger requested review of D18570: EGLStream DRM Backend Initial Implementation.
Jan 27 2019, 9:44 PM · KWin

Jan 22 2019

ekurzinger added a comment to D18376: Fix software cursors with drm backend.

Thanks for taking a look, David. Regarding your suggestion, do you think it would make more sense then to connect Platform::cursorChanged to the texture update function in scene_opengl.cpp instead of Cursor::cursorChanged? I'm not entirely clear on the distinction between those two signals, but the former does get emitted when the cursor changes while it seems the latter does not at the moment.

Jan 22 2019, 9:20 PM · KWin

Jan 18 2019

ekurzinger requested review of D18376: Fix software cursors with drm backend.
Jan 18 2019, 10:48 PM · KWin

Jan 17 2019

ekurzinger added a comment to D18307: Call frameRendered for undamaged Wayland surfaces.
In D18307#394965, @zzag wrote:

@ekurzinger Do you have commit access?

Jan 17 2019, 7:15 PM · KWin
ekurzinger updated the diff for D18307: Call frameRendered for undamaged Wayland surfaces.
Jan 17 2019, 7:12 PM · KWin

Jan 16 2019

ekurzinger added a reviewer for D18307: Call frameRendered for undamaged Wayland surfaces: romangg.
Jan 16 2019, 11:21 PM · KWin
ekurzinger removed a project from T10362: Call frameRendered for undamaged Wayland surfaces: Plasma on Wayland.
Jan 16 2019, 11:20 PM · KWin
ekurzinger added a project to T10362: Call frameRendered for undamaged Wayland surfaces: Plasma on Wayland.
Jan 16 2019, 11:19 PM · KWin
ekurzinger moved T10362: Call frameRendered for undamaged Wayland surfaces from Work In Progress to Under Review on the KWin board.
Jan 16 2019, 11:19 PM · KWin
ekurzinger added a revision to T10362: Call frameRendered for undamaged Wayland surfaces: D18307: Call frameRendered for undamaged Wayland surfaces.
Jan 16 2019, 11:19 PM · KWin
ekurzinger added a task to D18307: Call frameRendered for undamaged Wayland surfaces: T10362: Call frameRendered for undamaged Wayland surfaces.
Jan 16 2019, 11:19 PM · KWin
ekurzinger requested review of D18307: Call frameRendered for undamaged Wayland surfaces.
Jan 16 2019, 11:18 PM · KWin
ekurzinger moved T10362: Call frameRendered for undamaged Wayland surfaces from Backlog to Work In Progress on the KWin board.
Jan 16 2019, 11:00 PM · KWin
ekurzinger triaged T10362: Call frameRendered for undamaged Wayland surfaces as Normal priority.
Jan 16 2019, 11:00 PM · KWin

Oct 26 2018

ekurzinger added a comment to D16430: [effects/desktopgrid] Specify screen projection matrix when drawing moving window.

Hi David, thanks for taking a look! Note that I haven't got commit access so I believe someone will need to merge on my behalf. For authorship information, my name is Erik Kurzinger and email is ekurzinger@nvidia.com.

Oct 26 2018, 1:55 AM · KWin

Oct 25 2018

ekurzinger requested review of D16430: [effects/desktopgrid] Specify screen projection matrix when drawing moving window.
Oct 25 2018, 10:06 PM · KWin

Oct 20 2018

ekurzinger added a comment to D16278: [effects/presentwindows] Avoid potential freeze during fill-gaps.
In D16278#345365, @zzag wrote:

The freeze is still intermittent, but using this method should be able to be triggered within about 10 tries without this fix.

Well, I wasted hours trying to reproduce the bug with no luck.

So did I! Good job.

Oct 20 2018, 3:12 PM · KWin
ekurzinger updated the diff for D16278: [effects/presentwindows] Avoid potential freeze during fill-gaps.
Oct 20 2018, 3:02 PM · KWin

Oct 17 2018

ekurzinger added a comment to D16278: [effects/presentwindows] Avoid potential freeze during fill-gaps.

Sure, I have a single dolphin window positioned in the top-left corner of the leftmost desktop with dimensions 750 by 500. For some reason, the tool-tip for the "Split" button seems to be the most consistent way, but maybe that's just my imagination.
I have a single 1920x1200 monitor, and 3 virtual desktops in a single row. I've attached my kwinrc file in case there's anything else relevant there. Animation speed is set to 4, and the compositor backend is set to OpenGL 3.1

Oct 17 2018, 6:08 PM · KWin
ekurzinger updated the test plan for D16278: [effects/presentwindows] Avoid potential freeze during fill-gaps.
Oct 17 2018, 5:36 PM · KWin
ekurzinger added a comment to D16278: [effects/presentwindows] Avoid potential freeze during fill-gaps.

Hi Vlad,

Oct 17 2018, 5:23 PM · KWin
ekurzinger updated the summary of D16278: [effects/presentwindows] Avoid potential freeze during fill-gaps.
Oct 17 2018, 4:30 PM · KWin
ekurzinger updated the summary of D16278: [effects/presentwindows] Avoid potential freeze during fill-gaps.
Oct 17 2018, 4:30 PM · KWin
ekurzinger requested review of D16278: [effects/presentwindows] Avoid potential freeze during fill-gaps.
Oct 17 2018, 4:29 PM · KWin