bugGNU Octave - Bugs: bug #44125, mxe-octave: fltk printing displays...


bug #44125: mxe-octave: fltk printing displays line dropouts in dev version

Submitted by:  John Donoghue <lostbard>
Submitted on:  Thu 29 Jan 2015 08:36:33 PM UTC  
Category:  Plotting Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Fixed Assigned to:  None
Originator Name:  JohnD Open/Closed:  Closed
Release:  dev Operating System:  Microsoft Windows

Add a New Comment (Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


( Jump to the original submission)

Mon 16 Feb 2015 12:31:21 AM UTC, comment #12: 

On a new build it appears to work ok, so maybe I had something out of sync on my build.

Works for me.

John Donoghue <lostbard>
Project Member
Sun 15 Feb 2015 08:49:50 PM UTC, comment #11: 

print a.png

worked for me. Did not see any dropout. Which command failed for you?

Avinoam Kalma <avinoam>
Project Member
Sun 15 Feb 2015 06:30:55 PM UTC, comment #10: 

Doesnt fix it for me - same dropout occurs, although perhaps the line is a little darker.

John Donoghue <lostbard>
Project Member
Sat 14 Feb 2015 05:34:36 PM UTC, comment #9: 

Applied patch in bug #44111.  This now works for me on my MXE octave build.  I have marked the bug as Ready for Test and if someone else can verify that the problem is gone then I will close this bug.

Rik <rik5>
Project Administrator
Fri 13 Feb 2015 11:07:07 PM UTC, comment #8: 

This bug is fixed if we apply the patch in bug #44111.  The problem is that we have not be using the gl2ps POLYGON_OFFSET correctly.

Rik <rik5>
Project Administrator
Mon 02 Feb 2015 05:03:07 PM UTC, comment #7: 

What are the performance implications of just using GL2PS_BSP_SORT all the time?

According to the documentation for gl2ps:

Specifies the sorting algorithm, chosen among:

    The primitives are not sorted, and are output in stream in the order they appear in the feedback buffer. This is sufficient for two-dimensional scenes.
    The primitives are sorted according to their barycenter. This can be sufficient for simple three-dimensional scenes and/or when correctness is not crucial.
    The primitives are inserted in a Binary Space Partition (BSP) tree. The tree is then traversed back to front in a painter-like algorithm. This should be used whenever an accurate rendering of a three-dimensional scene is sought. Beware that this algorithm requires a lot more computational time (and memory) than the simple barycentric sort.

I changed from NO_SORT to SIMPLE_SORT to correctly handle the 'layer' attribute for axes (either in front of or behind the 2-D objects on the screen).  I would think that most of the time the GL2PS_BSP_SORT wouldn't actually be much more time consuming for your average 2-D plot.  However, there are probably some situations, like a scatter plot with 99 points, which might show a difference.

If benchmarking doesn't show much of a change I would be fine changing the default to BSP_SORT.

Rik <rik5>
Project Administrator
Fri 30 Jan 2015 08:12:16 PM UTC, comment #6: 

If I run drawnow as per previous comment (your patch is still applied) then the resulting out.eps looks good!

John Donoghue <lostbard>
Project Member
Fri 30 Jan 2015 05:43:16 PM UTC, comment #5: 

Do you see a difference if you force GL2PS_BSP_SORT?

drawnow ("eps", "cat > out.eps");

If I remember correctly gl2ps_sort has changed from GL2PS_NO_SORT to GL2PS_SIMPLE_SORT between 3.8.2 and 4.1. cset 652d9ed6f88d

Andreas Weber <andy1978>
Project Member
Fri 30 Jan 2015 04:21:42 PM UTC, comment #4: 

I just verified - rebuilding 3.8.2 using all the same other libraries (ghostscript, libpng, epstool etc) as I had built the 4.1.0+ version.

In 3.8.2, the printed plot in fltk displays ok. In 4.1.0+, it does not.

John Donoghue <lostbard>
Project Member
Fri 30 Jan 2015 08:47:12 AM UTC, comment #3: 

Thats interesting. All other reporter of this (missing or broken lines with MXE-Octave on Windows with FLTK or Qt) had the same problem on Octave 3.8.2 and 4.1.0.

For some of them installing the Mesa driver helped: http://wiki.octave.org/FAQ#Missing_lines_when_printing_under_Windows_with_OpenGL_toolkit_and_Intel_integrated_GPU

Andreas Weber <andy1978>
Project Member
Thu 29 Jan 2015 09:51:51 PM UTC, comment #2: 

Maybe - I do have a Intel HD Graphics 3000.

fltk printing worked fine in octave 3.8.2 but not the dev 4.1.0.

John Donoghue <lostbard>
Project Member
Thu 29 Jan 2015 09:46:18 PM UTC, comment #1: 

Is this a duplicate of bug #42534?

Andreas Weber <andy1978>
Project Member
Thu 29 Jan 2015 08:36:33 PM UTC, original submission:  

Spawned from https://savannah.gnu.org/bugs/?42537.

Printing using fltk has lines that display dropouts in the thickness of the line.

Can be seen by:

print t.png

Printing was working ok in mxe-octave 3.8.2.

John Donoghue <lostbard>
Project Member


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

Attach Files:

No files currently attached


   bug dependencies.

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by avinoam (Posted a comment)
  • -email is unavailable- added by avinoam
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by andy1978 (Posted a comment)
  • -email is unavailable- added by lostbard (Submitted the item)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.




    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2015-02-16 rik5 StatusReady For Test => Fixed
        Open/ClosedOpen => Closed
    2015-02-14 rik5 StatusIn Progress => Ready For Test
    2015-02-13 rik5 Dependencies- => Depends on bugs #44111
    2015-02-12 avinoam Carbon-Copy- => Added avinoam
    2015-02-02 rik5 StatusNone => In Progress

    Back to the top

    Powered by Savane 3.6