Bug 182810 - [OpenGL] GLCanvas.isCurrent() always returns false on Windows
Summary: [OpenGL] GLCanvas.isCurrent() always returns false on Windows
Status: RESOLVED FIXED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: SWT (show other bugs)
Version: 3.3   Edit
Hardware: PC Windows XP
: P3 normal with 2 votes (vote)
Target Milestone: 3.3 M7   Edit
Assignee: Steve Northover CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-04-17 15:05 EDT by Jeff Norris CLA
Modified: 2007-05-17 17:10 EDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jeff Norris CLA 2007-04-17 15:05:43 EDT
On Windows, the following bit of code is an infinite loop.  On Linux, it is not.

while (!myGLCanvas.isCurrent())
   myGLCanvas.setCurrent();

In other words, GLCanvas.isCurrent() always returns false on Windows, even if GLCanvas.setCurrent() has just been called.  This is a big problem for us because GLCanvas.setCurrent() does some time consuming things and we need to minimize the number of times we have to call it.

Poking into isCurrent and setCurrent, I see that both actually perform the same check:

  WGL.wglGetCurrentContext () == handle

It is this native method that doesn't seem to work on Windows.  For what it's worth, calling wglGetCurrentContext() on Windows returns 65536 (yes, precisely 2^16) when the GLCanvas that is created first is active.  It returns 65537 when the GLCanvas that is created second is active, and so on.  These are certainly suspicious looking numbers.  Meanwhile, the values of handle are more random looking things like 1771094, 1901578, 657418.  On Linux, wlGetCurrentContext() returns random looking values that match the value of handle.  

Again, just to be abundantly clear - this problem exists on Windows but not on Linux.  We haven't checked yet, but I suspect that it also does not exist on Mac since the symptom that alerted us to this issue is relatively poor GL performance on Windows compared to Linux and Mac.
Comment 1 Steve Northover CLA 2007-04-18 01:52:22 EDT
Fixed > 20070418

Can you verify that "relatively poor GL performance on Windows" is either fixed by this bug or not caused by SWT?  (ie. Windows OpenGL is just slow) 
Comment 2 Jeff Norris CLA 2007-04-18 16:20:56 EDT
We haven't tried the build with your fix yet.  However, we did find a way to (temporarily) drastically reduce how often we call setCurrent() and performance on Windows improved significantly.  Our impression is that it is still deficient compared to Linux and Mac but the difference is much less pronounced.  We're working these issues actively now and will report more data when we have it.

Thanks!
Comment 3 Steve Northover CLA 2007-04-18 16:28:53 EDT
If SWT is to blame for this, I want to fix it.  If Java or Windows is at fault, I want to do the best I can to get whatever performance I can to you.

See bug 176150 for more information about wierd Windows slowness.  Feel free to investigate that puppy and let us know.