Re: GLWindow
Posted by Sven Gothel on Feb 05, 2013; 10:05pm
URL: https://forum.jogamp.org/GLWindow-tp4027817p4028151.html
On 02/04/2013 07:00 PM, Daniel Avila [via jogamp] wrote:
> I'm having the same issues with the autobuild. Maybe I'm approaching this from
> the wrong angle.
>
> Take a look at this test case <https://gist.github.com/4707452>, which
> demonstrates the fundamental limitation I'm running into. /*WARNING*/ : this
> test causes significant flickering in the screen, and my hurt your eyes. All
> the test does is repeatedly clear the viewing surface with a black and white
> background, which should be a trivial operation.
I see .. :)
>
> It is not entirely clear what else is gained when entering Fullscreen, but at
> the very least we are able to sync with the monitor's refresh rate. Unless
> there is a way to vsync in windowed view, you will see skipping in the
> animation regardless of GL work being done and the FPS you can achieve.
I see you have enabled VSYNC, good:
gl.setSwapInterval(1);
>
> I've noticed that the more powerful your graphics card is, the less obvious
> this problem is. We tested with a GTX 690 using its parallel performance mode,
> and still had the skipping problem which we identified using an oscilloscope.
> And it is not just JOGL ... AWT/SWING, LWJGL, and even D3D had the same problem.
>
> Now, it is my understanding that JOGL uses WGL and GDI as the native Windows
> implementation. After reading this article on MSDN
> <http://msdn.microsoft.com/en-us/library/windows/desktop/dd183314%28v=vs.85%29.aspx>,
> it sounds like what I'm trying to do is simply not possible.
>
> The newer graphics architecture, DXGI, does support multiple fullscreen swap
> chains
> <http://msdn.microsoft.com/en-us/library/ee417025.aspx#multiple_monitors>.
> However, I doubt any of us have the time to implement JOGL on DXGI. It might
> be worth putting on the roadmap though, and I would be interested in working
> on this in the future.
>
> I don't think it would be easy to port to D3D, since none of us have worked
> with the architecture and I doubt there are bindings for it in Java that are
> as intuitive as JOGL. Not to mention that kills our portability in the future.
>
> As an interim solution, I have the ability to span exactly 3 monitors with the
> GTX 690 (I haven't tested it yet though), which means I could probably get
> away with a single canvas. It's not an ideal situation, but it should work.
>
> If you guys have any other suggestions or routes I could explore, please feel
> free to post them here.You seem to experience 'tearing' due to incorrect VSYNC.
We use the platform agnostic OpenGL API
and platform dependent windowing bindings APIs EGL, GLX, WGL, CGL, ..
'gl.setSwapInterval(1);' invokes the EGL, GLX, WGL, CGL .. equivalent call.
It is up to the driver implementer to make this function work properly
regardless of windowing- or fullscreen-mode.
Of course, in fullscreen mode it is easy to get the VSYNC right,
since no other renderer activity is being performed.
In windowing mode users see different artifacts every now and then.
For example on X11/ATI-proprietary the actual swap-interval value is
multiplied be the many windows requesting one, e.g.:
4 windows -> vsync on every 4 frames
On X11/NVidia I haven't experienced tearing, but I also haven't
checked too closely.
In your case VSYNC seems to be ignored.
The VSYNC behavior also depends heavily on the window manager (WM) mode,
i.e. compositing or 'direct' - so respecting OS, driver and WM
we get quite a huge dimensional space for error here.
There is on OpenGL related extension: WGL_NV_swap_group
which is abstracted in GLContext. However this extension is
related to NVidia only and only supported in the professional cards/drivers.
See unit test: com.jogamp.opengl.test.junit.jogl.acore.TestNVSwapGroupNEWT
http://jogamp.org/git/?p=jogl.git;a=blob;f=src/test/com/jogamp/opengl/test/junit/jogl/acore/TestNVSwapGroupNEWT.java;h=54f99433cc8bbaa77d0675bf3d3ed47c7f4e753e;hb=HEAD#l75
Since this is not a native JOGL issue and if this is really important to you,
my recommendation is to check combinations of drivers (incl. OS) and WM modes.
You may like to test w/ compositing turned off .. etc.
If there is a reliable way for your WM .. we may be able to add a quirk/workaround.
Maybe you like to document a WM/WM-Mode/OS/driver matrix regarding VSYNC.
~Sven
URL: https://forum.jogamp.org/GLWindow-tp4027817p4028151.html
On 02/04/2013 07:00 PM, Daniel Avila [via jogamp] wrote:
> I'm having the same issues with the autobuild. Maybe I'm approaching this from
> the wrong angle.
>
> Take a look at this test case <https://gist.github.com/4707452>, which
> demonstrates the fundamental limitation I'm running into. /*WARNING*/ : this
> test causes significant flickering in the screen, and my hurt your eyes. All
> the test does is repeatedly clear the viewing surface with a black and white
> background, which should be a trivial operation.
I see .. :)
>
> It is not entirely clear what else is gained when entering Fullscreen, but at
> the very least we are able to sync with the monitor's refresh rate. Unless
> there is a way to vsync in windowed view, you will see skipping in the
> animation regardless of GL work being done and the FPS you can achieve.
I see you have enabled VSYNC, good:
gl.setSwapInterval(1);
>
> I've noticed that the more powerful your graphics card is, the less obvious
> this problem is. We tested with a GTX 690 using its parallel performance mode,
> and still had the skipping problem which we identified using an oscilloscope.
> And it is not just JOGL ... AWT/SWING, LWJGL, and even D3D had the same problem.
>
> Now, it is my understanding that JOGL uses WGL and GDI as the native Windows
> implementation. After reading this article on MSDN
> <http://msdn.microsoft.com/en-us/library/windows/desktop/dd183314%28v=vs.85%29.aspx>,
> it sounds like what I'm trying to do is simply not possible.
>
> The newer graphics architecture, DXGI, does support multiple fullscreen swap
> chains
> <http://msdn.microsoft.com/en-us/library/ee417025.aspx#multiple_monitors>.
> However, I doubt any of us have the time to implement JOGL on DXGI. It might
> be worth putting on the roadmap though, and I would be interested in working
> on this in the future.
>
> I don't think it would be easy to port to D3D, since none of us have worked
> with the architecture and I doubt there are bindings for it in Java that are
> as intuitive as JOGL. Not to mention that kills our portability in the future.
>
> As an interim solution, I have the ability to span exactly 3 monitors with the
> GTX 690 (I haven't tested it yet though), which means I could probably get
> away with a single canvas. It's not an ideal situation, but it should work.
>
> If you guys have any other suggestions or routes I could explore, please feel
> free to post them here.
We use the platform agnostic OpenGL API
and platform dependent windowing bindings APIs EGL, GLX, WGL, CGL, ..
'gl.setSwapInterval(1);' invokes the EGL, GLX, WGL, CGL .. equivalent call.
It is up to the driver implementer to make this function work properly
regardless of windowing- or fullscreen-mode.
Of course, in fullscreen mode it is easy to get the VSYNC right,
since no other renderer activity is being performed.
In windowing mode users see different artifacts every now and then.
For example on X11/ATI-proprietary the actual swap-interval value is
multiplied be the many windows requesting one, e.g.:
4 windows -> vsync on every 4 frames
On X11/NVidia I haven't experienced tearing, but I also haven't
checked too closely.
In your case VSYNC seems to be ignored.
The VSYNC behavior also depends heavily on the window manager (WM) mode,
i.e. compositing or 'direct' - so respecting OS, driver and WM
we get quite a huge dimensional space for error here.
There is on OpenGL related extension: WGL_NV_swap_group
which is abstracted in GLContext. However this extension is
related to NVidia only and only supported in the professional cards/drivers.
See unit test: com.jogamp.opengl.test.junit.jogl.acore.TestNVSwapGroupNEWT
http://jogamp.org/git/?p=jogl.git;a=blob;f=src/test/com/jogamp/opengl/test/junit/jogl/acore/TestNVSwapGroupNEWT.java;h=54f99433cc8bbaa77d0675bf3d3ed47c7f4e753e;hb=HEAD#l75
Since this is not a native JOGL issue and if this is really important to you,
my recommendation is to check combinations of drivers (incl. OS) and WM modes.
You may like to test w/ compositing turned off .. etc.
If there is a reliable way for your WM .. we may be able to add a quirk/workaround.
Maybe you like to document a WM/WM-Mode/OS/driver matrix regarding VSYNC.
~Sven
signature.asc (911 bytes) | Free forum by Nabble | Edit this page |