Incorrect handling of IME messages #19

Closed
thefiddler opened this Issue Dec 17, 2013 · 2 comments

Comments

Projects
None yet
1 participant
Contributor

thefiddler commented Dec 17, 2013

Originally reported here: http://www.opentk.com/node/2479

When using specific Nvidia GPUs and drivers, it appears that wglGetProcAddress takes a long time to return, to the point were loading all entry points takes time in the order seconds.

This issue does not appear to affect the SDL2 backend, or AMD/Intel GPUs. Upgrading Nvidia drivers has been known to help.

We need to find what is causing this issue and fix it. For this, we need the help of someone with a system that reproduces the problem.

thefiddler added a commit that referenced this issue Dec 17, 2013

thefiddler added a commit that referenced this issue Dec 17, 2013

Use gdi32 implementations of functions
Several functions are defined in both gdi32 and opengl32. Using the
opengl32/wgl versions did not appear to help with issue #19. Let's use
the gdi32 version instead, as suggested here:
https://www.opengl.org/wiki/Platform_specifics:_Windows#The_WGL_functions

thefiddler added a commit that referenced this issue Dec 18, 2013

Cleaned up temporary context construction
The temporary context is now retained until the actual context has been
constructed. If we don't do this, then WGL_ARB_create_context may fail
to work correctly on specific GPUs (e.g. Intel). This may affect issue
#19.

thefiddler added a commit that referenced this issue Dec 19, 2013

Contributor

thefiddler commented Dec 20, 2013

The following code reproduces this issue:

using (var window = new OpenTK.NativeWindow())
{
    while (window.Exists)
    {
        window.ProcessEvents();
    }
}

This means that the issue is isolated within OpenTK.Platform.Windows.WinGLNative and is not affected by WinGLContext or anything OpenGL-related. Additionally, disabling input processing (WinInputBase) and message handling (WinGLNative.WindowProcedure) does not appear to make a difference.

More testing indicates that the lag appears when the window receives a WM_IME* message. When that happens:

  1. the windows taskbar stops responding for a few seconds
  2. the language picker icon disappears
  3. the taskbar starts responding again

As soon as the user drags the window from its frame (move or resize), the issue goes away and never appears again.

Edit: additional information on IME handling. Consuming the WM_IME_NOTIFY message appears to fix the lag issue.

thefiddler added a commit that referenced this issue Dec 20, 2013

Fix issue #19
Don't filter window messages passed to our window (see
http://blogs.msdn.com/b/oldnewthing/archive/2005/02/09/369804.aspx).
Additionally, return the correct values for all messages we are actually
handling and clean up unmanaged memory after we are done with the
window.
Contributor

thefiddler commented Dec 20, 2013

The explanation and solution to this issue can be found here: http://blogs.msdn.com/b/oldnewthing/archive/2005/02/09/369804.aspx

@thefiddler thefiddler closed this Dec 20, 2013

thefiddler added a commit that referenced this issue Dec 20, 2013

Revert "Fix issue #19"
This reverts commit 2c14ec5.

thefiddler added a commit that referenced this issue Dec 20, 2013

Clean fix issue #19
Isolate and commit fix for issue #19 without potential for regressions.

thefiddler added a commit that referenced this issue Dec 22, 2013

thefiddler added a commit that referenced this issue Dec 22, 2013

Use gdi32 implementations of functions
Several functions are defined in both gdi32 and opengl32. Using the
opengl32/wgl versions did not appear to help with issue #19. Let's use
the gdi32 version instead, as suggested here:
https://www.opengl.org/wiki/Platform_specifics:_Windows#The_WGL_functions

thefiddler added a commit that referenced this issue Dec 22, 2013

Cleaned up temporary context construction
The temporary context is now retained until the actual context has been
constructed. If we don't do this, then WGL_ARB_create_context may fail
to work correctly on specific GPUs (e.g. Intel). This may affect issue
#19.

thefiddler added a commit that referenced this issue Dec 22, 2013

thefiddler added a commit that referenced this issue Dec 22, 2013

Fix issue #19
Don't filter window messages passed to our window (see
http://blogs.msdn.com/b/oldnewthing/archive/2005/02/09/369804.aspx).
Additionally, return the correct values for all messages we are actually
handling and clean up unmanaged memory after we are done with the
window.

thefiddler added a commit that referenced this issue Dec 22, 2013

Revert "Fix issue #19"
This reverts commit 2c14ec5.

thefiddler added a commit that referenced this issue Dec 22, 2013

Clean fix issue #19
Isolate and commit fix for issue #19 without potential for regressions.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment