public inbox for cygwin-xfree@sourceware.org
help / color / mirror / Atom feed
From: "A.R. Burgers" <a.rburgers@quicknet.nl>
To: cygwin-xfree@cygwin.com
Subject: Re: fltk / gl rendering problem
Date: Mon, 24 Jun 2013 20:31:00 -0000	[thread overview]
Message-ID: <51C8ACA2.5090107@quicknet.nl> (raw)
In-Reply-To: <51C86330.8060304@dronecode.org.uk>

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/


      reply	other threads:[~2013-06-24 20:31 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <51BDCFCE.3060608@gmail.com>
2013-06-16 14:51 ` marco atzeri
2013-06-17  6:48   ` marco atzeri
2013-06-21 11:32     ` Jon TURNEY
2013-06-23 13:56       ` marco atzeri
2013-06-24 15:18         ` Jon TURNEY
2013-06-24 20:31           ` A.R. Burgers [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=51C8ACA2.5090107@quicknet.nl \
    --to=a.rburgers@quicknet.nl \
    --cc=cygwin-xfree@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).