Re: fltk / gl rendering problem
On 23/06/2013 14:56, marco atzeri wrote: Il 6/21/2013 1:32 PM, Jon TURNEY ha scritto: On 17/06/2013 07:48, marco atzeri wrote: Il 6/16/2013 4:51 PM, marco atzeri ha scritto: testing a octave/fltk graphics issue, I noticed that also the demo of fltk with GL interface has a similar issue. Thanks for reporting this and thanks for providing the test binaries. On http://matzeri.altervista.org/works/fltk_gl/ I uploaded the before and after apperance of gl_overlay demo. It is enough to move the window to loose the geometrical image while the bars are correctly re-drawn. Running Xwin with -wgl does not show such defect, but it is terribly slow. So I assume it is not a fltk defect but of GL or XServer. I guess this should read with -nowgl, in which case, this is a limitation of the current implementation of -wgl mode, which will require lots of work to fix. Question: is -wgl disabled by some of the other Xwin options ? I was sure all my previous experiments where with -wgl But I see no difference between xwin -rootless -nowgl and xwin -rootless -wgl is only available in -multiwindow mode: (II) GLX: Initialized Win32 native WGL GL provider for screen 0 If you try it in any other mode, you'll get the following in the log: (EE) AIGLX: No native OpenGL in modes with a root window ... (II) AIGLX: Loaded and initialized swrast This could probably do with being better documented. The reason for this restriction is that the only way to constrain OpenGL drawing to a given region is make a Windows window which occupies that region. In the initial WGL implementation, these Windows windows were the ones corresponding to the top-level X windows we have in multiwindow mode. I subsequently added a bit of trickery which makes things somewhat work for non-top-level X windows, by creating a hidden Windows window hierarchy, which puts a Windows window in the right place to make the OpenGL drawing appear in the right place and at the right size, but because that drawing isn't composed into the X screen, but drawn on top of it, we get these issues. In theory this trick could be extended to provide WGL in modes other than multiwindow, but these issues would also appear. I wrote a bit about these limitations at [1] [1] http://www.cygwin.com/ml/cygwin-xfree/2012-10/msg9.html It seems the same defect so it seems related to -wgl, at least in multiwindow mode. Testing with xwin -multiwindow the moving defect is present and slide layer are drawn xwin -multiwindow -nowgl the moving defect is NOT present but the slide layer are NOT drawn ( same for both xwin -rootless -nowgl and xwin -rootless ) further experiment showed that the defect is present when the integrate windows manager is used. With external window manager (fvwm, openbox,.. ) that defect does not apper. With external window manager another defect appears, the upper bar effect is not shown at all; while it is present on the integrated window manager. When I tested this, it looks like the solid area controlled by the sides slider didn't get rendered into a separate layer when using software rendering (either -nowgl or X server in windowed mode), so this is possibly some bug or limitation in the software renderer, or possibly in a bug in the demo not recognizing the lack of capabilities of the software renderer. Do you mean more likely a OpenGL bug of fltk one ? One or the other, yes :) In a brief test, the gl_overlay demo appears the same using the software renderer under linux. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: fltk / gl rendering problem
Op 2013-06-24 17:18, Jon TURNEY schreef: On 23/06/2013 14:56, marco atzeri wrote: Il 6/21/2013 1:32 PM, Jon TURNEY ha scritto: On 17/06/2013 07:48, marco atzeri wrote: Il 6/16/2013 4:51 PM, marco atzeri ha scritto: testing a octave/fltk graphics issue, I noticed that also the demo of fltk with GL interface has a similar issue. Thanks for reporting this and thanks for providing the test binaries. On http://matzeri.altervista.org/works/fltk_gl/ I uploaded the before and after apperance of gl_overlay demo. It is enough to move the window to loose the geometrical image while the bars are correctly re-drawn. Running Xwin with -wgl does not show such defect, but it is terribly slow. So I assume it is not a fltk defect but of GL or XServer. I guess this should read with -nowgl, in which case, this is a limitation of the current implementation of -wgl mode, which will require lots of work to fix. Question: is -wgl disabled by some of the other Xwin options ? I was sure all my previous experiments where with -wgl But I see no difference between xwin -rootless -nowgl and xwin -rootless -wgl is only available in -multiwindow mode: (II) GLX: Initialized Win32 native WGL GL provider for screen 0 If you try it in any other mode, you'll get the following in the log: (EE) AIGLX: No native OpenGL in modes with a root window ... (II) AIGLX: Loaded and initialized swrast This could probably do with being better documented. The reason for this restriction is that the only way to constrain OpenGL drawing to a given region is make a Windows window which occupies that region. In the initial WGL implementation, these Windows windows were the ones corresponding to the top-level X windows we have in multiwindow mode. I subsequently added a bit of trickery which makes things somewhat work for non-top-level X windows, by creating a hidden Windows window hierarchy, which puts a Windows window in the right place to make the OpenGL drawing appear in the right place and at the right size, but because that drawing isn't composed into the X screen, but drawn on top of it, we get these issues. In theory this trick could be extended to provide WGL in modes other than multiwindow, but these issues would also appear. I wrote a bit about these limitations at [1] [1] http://www.cygwin.com/ml/cygwin-xfree/2012-10/msg9.html It seems the same defect so it seems related to -wgl, at least in multiwindow mode. Testing with xwin -multiwindow the moving defect is present and slide layer are drawn xwin -multiwindow -nowgl the moving defect is NOT present but the slide layer are NOT drawn ( same for both xwin -rootless -nowgl and xwin -rootless ) further experiment showed that the defect is present when the integrate windows manager is used. With external window manager (fvwm, openbox,.. ) that defect does not apper. With external window manager another defect appears, the upper bar effect is not shown at all; while it is present on the integrated window manager. When I tested this, it looks like the solid area controlled by the sides slider didn't get rendered into a separate layer when using software rendering (either -nowgl or X server in windowed mode), so this is possibly some bug or limitation in the software renderer, or possibly in a bug in the demo not recognizing the lack of capabilities of the software renderer. Do you mean more likely a OpenGL bug of fltk one ? One or the other, yes :) In a brief test, the gl_overlay demo appears the same using the software renderer under linux. Not sure whether this is related, this one is not specific to OpenGL, but I had a rendering issue as well http://www.fltk.org/str.php?L2845 Teun -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: fltk / gl rendering problem
Il 6/21/2013 1:32 PM, Jon TURNEY ha scritto: On 17/06/2013 07:48, marco atzeri wrote: Il 6/16/2013 4:51 PM, marco atzeri ha scritto: testing a octave/fltk graphics issue, I noticed that also the demo of fltk with GL interface has a similar issue. Thanks for reporting this and thanks for providing the test binaries. On http://matzeri.altervista.org/works/fltk_gl/ I uploaded the before and after apperance of gl_overlay demo. It is enough to move the window to loose the geometrical image while the bars are correctly re-drawn. Running Xwin with -wgl does not show such defect, but it is terribly slow. So I assume it is not a fltk defect but of GL or XServer. I guess this should read with -nowgl, in which case, this is a limitation of the current implementation of -wgl mode, which will require lots of work to fix. Question: is -wgl disabled by some of the other Xwin options ? I was sure all my previous experiments where with -wgl But I see no difference between xwin -rootless -nowgl and xwin -rootless I wrote a bit about these limitations at [1] [1] http://www.cygwin.com/ml/cygwin-xfree/2012-10/msg9.html It seems the same defect so it seems related to -wgl, at least in multiwindow mode. Testing with xwin -multiwindow the moving defect is present and slide layer are drawn xwin -multiwindow -nowgl the moving defect is NOT present but the slide layer are NOT drawn ( same for both xwin -rootless -nowgl and xwin -rootless ) further experiment showed that the defect is present when the integrate windows manager is used. With external window manager (fvwm, openbox,.. ) that defect does not apper. With external window manager another defect appears, the upper bar effect is not shown at all; while it is present on the integrated window manager. When I tested this, it looks like the solid area controlled by the sides slider didn't get rendered into a separate layer when using software rendering (either -nowgl or X server in windowed mode), so this is possibly some bug or limitation in the software renderer, or possibly in a bug in the demo not recognizing the lack of capabilities of the software renderer. Do you mean more likely a OpenGL bug of fltk one ? Regards Marco -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: fltk / gl rendering problem
On 17/06/2013 07:48, marco atzeri wrote: Il 6/16/2013 4:51 PM, marco atzeri ha scritto: testing a octave/fltk graphics issue, I noticed that also the demo of fltk with GL interface has a similar issue. Thanks for reporting this and thanks for providing the test binaries. On http://matzeri.altervista.org/works/fltk_gl/ I uploaded the before and after apperance of gl_overlay demo. It is enough to move the window to loose the geometrical image while the bars are correctly re-drawn. Running Xwin with -wgl does not show such defect, but it is terribly slow. So I assume it is not a fltk defect but of GL or XServer. I guess this should read with -nowgl, in which case, this is a limitation of the current implementation of -wgl mode, which will require lots of work to fix. I wrote a bit about these limitations at [1] [1] http://www.cygwin.com/ml/cygwin-xfree/2012-10/msg9.html further experiment showed that the defect is present when the integrate windows manager is used. With external window manager (fvwm, openbox,.. ) that defect does not apper. With external window manager another defect appears, the upper bar effect is not shown at all; while it is present on the integrated window manager. When I tested this, it looks like the solid area controlled by the sides slider didn't get rendered into a separate layer when using software rendering (either -nowgl or X server in windowed mode), so this is possibly some bug or limitation in the software renderer, or possibly in a bug in the demo not recognizing the lack of capabilities of the software renderer. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: fltk / gl rendering problem
Il 6/16/2013 4:51 PM, marco atzeri ha scritto: Hi, testing a octave/fltk graphics issue, I noticed that also the demo of fltk with GL interface has a similar issue. On http://matzeri.altervista.org/works/fltk_gl/ I uploaded the before and after apperance of gl_overlay demo. It is enough to move the window to loose the geometrical image while the bars are correctly re-drawn. Running Xwin with -wgl does not show such defect, but it is terribly slow. So I assume it is not a fltk defect but of GL or XServer. A copy of gl_overlay from fltk-1.3.1.9857-1 build is also uploaded. Regards Marco further experiment showed that the defect is present when the integrate windows manager is used. With external window manager (fvwm, openbox,.. ) that defect does not apper. With external window manager another defect appears, the upper bar effect is not shown at all; while it is present on the integrated window manager. Regards Marco -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
