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


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

Submitter:  John Donoghue <lostbard>
Submitted:  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
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment (Rich Markup)

Comment Type & Canned Response:


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

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