bugGNU Octave - Bugs: bug #41932, Solid line appears dashed with FLTK

 
 

bug #41932: Solid line appears dashed with FLTK

Submitter:  None
Submitted:  Sat 22 Mar 2014 09:17:08 AM UTC
   
 
Category:  Plotting Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Fixed Assigned to:  None
Originator Name:  Ma Long Originator Email:  -email is unavailable-
Open/Closed:  * Closed Release:  * 3.8.1
Operating System:  * GNU/Linux Fixed Release:  None
Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Tue 22 Apr 2014 07:20:17 PM UTC, comment #12: 

Ok, closing since we have done as much as we can imagine doing for the Intel cards with FLKT in the 3.8.1 release. As said, feel free to reply or open a new bug report if someone feels that the current appearance is not good enough.

See bug #41819 for the equivalent fix needed for the Qt toolkit.

Mike Miller <mtmiller>
Group Member
Tue 22 Apr 2014 02:45:37 PM UTC, comment #11: 

Mike, I noticed the FLTK fix. And, there have
been lots of related changes. I do not have
a non-Intel ystem handy right now, but I feel
that the linewidth that I see at 0.5 is OK.
And, of course, the print output looks quite
a lot better at 0.5.

So I would vote for closing this bug report.
But, with the usual mention that anyone who
thinks there is still a problem should request
reopenning it.


Michael Godfrey <godfrey>
Group Member
Tue 22 Apr 2014 01:40:53 PM UTC, comment #10: 

Michael, there was a fix made to Octave's FLTK interface in the 3.8.1 release that makes lines appear more solid, but still thinner than they do on other video cards. If you compare plots made with 3.8.0 and 3.8.1 with linewidth 0.5 it should be easy to see the difference.

So yes it is much improved, but the lines are still much thinner and fainter than on other video cards.

The screenshot attached to this bug report looks like the pre-3.8.1 behavior. The OP has not followed up to explain how that screenshot was obtained, but I don't see that with 3.8.1.

If we consider the plots we get now to be as good as we're going to get with Intel graphics, then we should just close this report as fixed with 3.8.1.

There's already another bug report open about making the same fix to the Qt plotting toolkit.

Mike Miller <mtmiller>
Group Member
Tue 22 Apr 2014 10:16:23 AM UTC, comment #9: 

Here is an observation on this long saga:
For a long time I have had to use:

set(0, "defaultaxeslinewidth", 1.0);
set(0, "defaultlinelinewidth", 1.0);

in order to get viewable plots. With widths
set to 0.5 not only were lines discontinuous,
but at some plot scales the axis and grid
lines would disappear altogether.

My system is x86_64 Intel with Intel graphics.
Fedora 20, now with most recent updates.

Over this period there have been many changes
to most of the graphics-related software:
X11, OpenGL, antialiasing in Octave, and so on.

Yesterday many of the graphics libraries were
updated on Fedora, such as xorg and many libs like:
mesa-libGL-10.1-6.20140305.fc20.x86_64

So, I tried some plots with widths set to 0.5.
They all look good so far! The lines are thin,
but no discontinuities, or missing lines.

I am sure that we have not heard the last of these
problems, but it is pretty certain that the
recent problems are not all Octave's fault.

It may make sense to think of an explanation
for users that may avoid some complaints.

I will do some more experiments, including
checking the effects on print outputs.





Michael Godfrey <godfrey>
Group Member
Mon 21 Apr 2014 09:13:01 AM UTC, comment #8: 

Is it possible to change the linewidth as
a part of the print process and then reset it?

Michael Godfrey <godfrey>
Group Member
Mon 21 Apr 2014 02:55:51 AM UTC, comment #7: 

This is a bit of a bummer.  Apparently the Intel chipset advertises that it can draw lines with 0.5 width, but can't in practice.  The OpenGL specification only requires a minimum of 1.0 be supported.  Conceivably we could always draw on-screen using a minimum of 1.0.  But then we would have the problem with printing.

Rik <rik5>
Group administrator
Sun 20 Apr 2014 04:14:26 PM UTC, comment #6: 

I have one of the integrated Intel chipsets that shows this issue with FLTK plots, here's the output of your test program for me:


aliased line width range 1.000000 - 5.000000
smooth line width range 1.000000 - 5.000000
smooth line granularity 0.500000


Michael is right, if I increase the line width to 1 so it looks solid on the screen, it appears thicker when printed to a png.

Mike Miller <mtmiller>
Group Member
Sun 20 Apr 2014 09:43:57 AM UTC, comment #5: 

Rik said:
"If this is the case, then we might be able to implement a solution in Octave by querying these values. If the user requests a line width that is too small we could just substitute the minimum. This may be what Matlab does which could explain why they are always able to draw lines, even if the width is specified as 0.5."

THis definitely seems like a good idea. It does appear that
Matlab does something like that.  In any case, this would
help quite a few users who spend time figuring out that they
need to increase linewidth.  Does this have implications for
the rendering to the print formats? i.e. should the increase
to the minimum only be applied for the drawing on screen?I think that this would be preferred, but at least it should be reviewed.

Michael Godfrey <godfrey>
Group Member
Sun 20 Apr 2014 02:29:48 AM UTC, comment #4: 

I think the problem lies with OpenGL.  I did some research and  OpenGL itself only supports a limited range of line widths.  It has one range for aliased (jagged) lines and another range for anti-aliased (smooth) lines.

I've attached code which will print out these ranges.  Unfortunately it's in C so you need to have the development packages for GL, GLU, and GLUT installed.  On Linux it compiles with


gcc -o rpt_lwidth rpt_lwidth.c -lGL -lGLU -lglut


In my case, the range of smooth lines is 1.0-5.0 and the granularity is 0.5 so I can construct lines from 0.5-5.5.

It would be useful if someone who is having this "dashed" line issue could compile and run the rpt_lwidth program.  My hunch is that the minimum smooth line width might be greater than 1.

If this is the case, then we might be able to implement a solution in Octave by querying these values.  If the user requests a line width that is too small we could just substitute the minimum.  This may be what Matlab does which could explain why they are always able to draw lines, even if the width is specified as 0.5.


(file #31216)

Rik <rik5>
Group administrator
Sat 22 Mar 2014 07:04:55 PM UTC, comment #3: 

This has been discussed a lot.  As far as we know, this is not a problem with Octave, but rather a problem with OpenGL and certain video drivers.

If someone is experiencing this problem and has access to Matlab on the same machine and it works we could try and debug it.

Rik <rik5>
Group administrator
Sat 22 Mar 2014 02:53:16 PM UTC, comment #2: 

Right. This has been discussed a lot.
Exactly where the problem occurs is not
clear. Intel graphics seem to be part of the
problem, but X11 is also likely a part.

In any case a simple solution is:

set(0, "defaultlinewidth", 1.0);

This could go in your .octaverc file.

An open question is why this appears not to affect
Matlab which uses a default of 0.5.

Michael Godfrey <godfrey>
Group Member
Sat 22 Mar 2014 01:17:39 PM UTC, comment #1: 

Do you have example code and perhaps an example figure?

I suspect it is just a matter of too small a line width.
On my Linux systems I also see discontinuous curved plots, adapting line width makes it better.

Philip Nienhuis <philipnienhuis>
Group Member
Sat 22 Mar 2014 09:17:08 AM UTC, original submission:  

     When I plot a figure with octave, I found the line is discontinuous. But if I run the print function to save this figure into a pdf file, the file is correct. I hope this bug will be rectified soon.

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #31216:  rpt_lwidth.c added by rik5 (907B - text/x-c)
file #31000:  OctaveBug.png added by None (11KiB - image/png)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by godfrey (Posted a comment)
  • -email is unavailable- added by None (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2014-04-22 mtmiller StatusDuplicate Fixed
        Open/ClosedOpen Closed
    2014-04-20 rik5 Attached File- Added rpt_lwidth.c, #31216
    2014-03-22 rik5 Item GroupPerformance Incorrect Result
        StatusNone Duplicate
        SummaryThe curves plotted is not continuous Solid line appears dashed with FLTK
    2014-03-22 None Attached File- Added OctaveBug.png, #31000

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code