fltk rendering problem

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

fltk rendering problem

Mike Miller
FLTK wisdom needed,

The attachment fltk-plot-debian-i965-dri shows what FLTK plots look
like to me on my regular development system. I had been wondering why
everyone thought FLTK was such an improvement :)

The attachment fltk-plot-good shows what I see now that I have tried
it on other boxes and I assume what everyone else is seeing. Looks
much better!

This "dotted line" effect on my display seems related to the default
line width being 0.5, if I set the line and axis widths to 1
everything looks more like the other screengrab. Does anyone see
anything similar to this? Or if you set your linewidth to an even
smaller fraction?

Debian testing, Mesa OpenGL 8.0.4, Intel xorg driver 2.20.2, i965 DRI
driver, in case any of those are known to cause problems.

--
mike

fltk-plot-debian-i965-dri.png (11K) Download Attachment
fltk-plot-good.png (9K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: fltk rendering problem

martin_helm
Am 12.10.2012 15:46, schrieb Mike Miller:

> FLTK wisdom needed,
>
> The attachment fltk-plot-debian-i965-dri shows what FLTK plots look
> like to me on my regular development system. I had been wondering why
> everyone thought FLTK was such an improvement :)
>
> The attachment fltk-plot-good shows what I see now that I have tried
> it on other boxes and I assume what everyone else is seeing. Looks
> much better!
>
> This "dotted line" effect on my display seems related to the default
> line width being 0.5, if I set the line and axis widths to 1
> everything looks more like the other screengrab. Does anyone see
> anything similar to this? Or if you set your linewidth to an even
> smaller fraction?
>
> Debian testing, Mesa OpenGL 8.0.4, Intel xorg driver 2.20.2, i965 DRI
> driver, in case any of those are known to cause problems.
>
Just to confirm when I run fltk backend on my openSUSE 12.2 notebook
with Intel Sandybridge and Mesa 8.0.4 I see the same effect, it looks
well on my other systems with proprietary nvidia drivers (same GNU/Linux
distro and version).
Looks like an anti aliasing problem, I need to look into the source code.
Reply | Threaded
Open this post in threaded view
|

Re: fltk rendering problem

bpabbott
Administrator
In reply to this post by Mike Miller

On Oct 12, 2012, at 9:46 AM, Mike Miller wrote:

> FLTK wisdom needed,
>
> The attachment fltk-plot-debian-i965-dri shows what FLTK plots look
> like to me on my regular development system. I had been wondering why
> everyone thought FLTK was such an improvement :)
>
> The attachment fltk-plot-good shows what I see now that I have tried
> it on other boxes and I assume what everyone else is seeing. Looks
> much better!
>
> This "dotted line" effect on my display seems related to the default
> line width being 0.5, if I set the line and axis widths to 1
> everything looks more like the other screengrab. Does anyone see
> anything similar to this? Or if you set your linewidth to an even
> smaller fraction?
>
> Debian testing, Mesa OpenGL 8.0.4, Intel xorg driver 2.20.2, i965 DRI
> driver, in case any of those are known to cause problems.
>
> --
> mike
> <fltk-plot-debian-i965-dri.png><fltk-plot-good.png>

On MacOS X I don't see the "dotted line" problem.  I assume that is due to poor and a lack of anti-aliasing?

Have you tried the Qt toolkit yet?

        https://github.com/goffioul/QtHandles

If I recall correctly, Qt includes anti-aliasing on all platforms.

Regarding "why everyone thought FLTK was such an improvement", it is not necessarily the quality of the displayed image that is improved.  What the FLTK backend improved was compatibility with regards to handle graphics.  For example, the FLTK backend *knows* the figure position and size.   This info is not available to the gnuplot backend (i.e. Octave is unable to determine if the user moves or resizes a gnuplot figure window).

Ben

Reply | Threaded
Open this post in threaded view
|

Re: fltk rendering problem

martin_helm
In reply to this post by martin_helm
Am 12.10.2012 15:57, schrieb Martin Helm:
>
> Just to confirm when I run fltk backend on my openSUSE 12.2 notebook
> with Intel Sandybridge and Mesa 8.0.4 I see the same effect, it looks
> well on my other systems with proprietary nvidia drivers (same GNU/Linux
> distro and version).
> Looks like an anti aliasing problem, I need to look into the source code.
Just to be sure I quickly made a small opengl program which draws a
antialiased line of width 0.5 and that works.
So it is not a problem of the graphics card driver or the mesa version.
Reply | Threaded
Open this post in threaded view
|

Re: fltk rendering problem

Dmitri A. Sergatskov
On Fri, Oct 12, 2012 at 10:41 AM, Martin Helm <[hidden email]> wrote:
...
> So it is not a problem of the graphics card driver or the mesa version.
...

FWIW:

I see this problem on the computer with intel graphics (i7-2600k/DZ68 m/b) and
I do not see on the computer with an nvidia card (and nvidia driver).
(GF106GL [Quadro 2000])

Dmitri.
--
Reply | Threaded
Open this post in threaded view
|

Re: fltk rendering problem

martin_helm
Am 12.10.2012 20:38, schrieb Dmitri A. Sergatskov:

> On Fri, Oct 12, 2012 at 10:41 AM, Martin Helm <[hidden email]> wrote:
> ...
>> So it is not a problem of the graphics card driver or the mesa version.
> ...
>
> FWIW:
>
> I see this problem on the computer with intel graphics (i7-2600k/DZ68 m/b) and
> I do not see on the computer with an nvidia card (and nvidia driver).
> (GF106GL [Quadro 2000])
>
> Dmitri.
> --
As I said I see exactly the same behavior (we have intel gpu and nvidia
gpu machines at home, all GNU/Linux systems), it is still not a driver
issue as my own test shows me.
The issue seems to be that something in octave (I will investigate the
details over the weekend) simply does not set proper state variables for
opengl and instead relies on whatever the implementation on the machine
does as default.
This is rarely what one would like to have.
So far I can also not understand what sense it makes to set a linewidth
of 0.5 without at the same time enabling antialiasing, the behavior what
an opengl implementation shall do in such a case seems to be undefined.
The nvidia driver just renders it aliased with a line width of 1, the
intel+mesa implementation seems to try to render "half" of the points.
So if by default we want aliased rendering we should probably have a
default line width which is an integer, not a fraction which cannot be
rendered in a defined way.

Reply | Threaded
Open this post in threaded view
|

Re: fltk rendering problem

Mike Miller
On Fri, Oct 12, 2012 at 2:47 PM, Martin Helm wrote:

> Am 12.10.2012 20:38, schrieb Dmitri A. Sergatskov:
>> On Fri, Oct 12, 2012 at 10:41 AM, Martin Helm <[hidden email]> wrote:
>> ...
>>> So it is not a problem of the graphics card driver or the mesa version.
>> ...
>>
>> FWIW:
>>
>> I see this problem on the computer with intel graphics (i7-2600k/DZ68 m/b) and
>> I do not see on the computer with an nvidia card (and nvidia driver).
>> (GF106GL [Quadro 2000])
>>
>> Dmitri.
>> --
> As I said I see exactly the same behavior (we have intel gpu and nvidia
> gpu machines at home, all GNU/Linux systems), it is still not a driver
> issue as my own test shows me.
> The issue seems to be that something in octave (I will investigate the
> details over the weekend) simply does not set proper state variables for
> opengl and instead relies on whatever the implementation on the machine
> does as default.
> This is rarely what one would like to have.
> So far I can also not understand what sense it makes to set a linewidth
> of 0.5 without at the same time enabling antialiasing, the behavior what
> an opengl implementation shall do in such a case seems to be undefined.
> The nvidia driver just renders it aliased with a line width of 1, the
> intel+mesa implementation seems to try to render "half" of the points.
> So if by default we want aliased rendering we should probably have a
> default line width which is an integer, not a fraction which cannot be
> rendered in a defined way.

Thanks for looking into this Martin. I guess I might as well post to
the bug tracker so we don't forget about this. Could you also share
the small opengl antialiasing test code you wrote?

--
mike
Reply | Threaded
Open this post in threaded view
|

Re: fltk rendering problem

martin_helm
Am 18.10.2012 21:19, schrieb Mike Miller:

> On Fri, Oct 12, 2012 at 2:47 PM, Martin Helm wrote:
>> Am 12.10.2012 20:38, schrieb Dmitri A. Sergatskov:
>>> On Fri, Oct 12, 2012 at 10:41 AM, Martin Helm <[hidden email]>
>>> wrote: ...
>>>> So it is not a problem of the graphics card driver or the mesa
>>>> version.
>>> ...
>>>
>>> FWIW:
>>>
>>> I see this problem on the computer with intel graphics
>>> (i7-2600k/DZ68 m/b) and I do not see on the computer with an
>>> nvidia card (and nvidia driver). (GF106GL [Quadro 2000])
>>>
>>> Dmitri. --
>> As I said I see exactly the same behavior (we have intel gpu and
>> nvidia gpu machines at home, all GNU/Linux systems), it is still
>> not a driver issue as my own test shows me. The issue seems to be
>> that something in octave (I will investigate the details over the
>> weekend) simply does not set proper state variables for opengl and
>> instead relies on whatever the implementation on the machine does
>> as default. This is rarely what one would like to have. So far I
>> can also not understand what sense it makes to set a linewidth of
>> 0.5 without at the same time enabling antialiasing, the behavior
>> what an opengl implementation shall do in such a case seems to be
>> undefined. The nvidia driver just renders it aliased with a line
>> width of 1, the intel+mesa implementation seems to try to render
>> "half" of the points. So if by default we want aliased rendering we
>> should probably have a default line width which is an integer, not
>> a fraction which cannot be rendered in a defined way.
>
> Thanks for looking into this Martin. I guess I might as well post to
> the bug tracker so we don't forget about this. Could you also share
> the small opengl antialiasing test code you wrote?
>
Will do as soon as I am back at home on Friday evening (I am on a
business trip at the moment), I hope I can propose some patch to solve this.
Please add an entry to the bug tracker.