fltk / gl rendering problem

fltk / gl rendering problem

[marco atzeri]

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





--
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

[marco atzeri]

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/

Re: fltk / gl rendering problem

[Jon TURNEY]

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/msg00009.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

[marco atzeri]

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/msg00009.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

[Jon TURNEY]

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/msg00009.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

[A.R. Burgers]

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/msg00009.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/