bugGNU Octave - Bugs: bug #35559, lines not printed

 
 

bug #35559: lines not printed

Submitted by:  Muhali <muhali>
Submitted on:  Fri 17 Feb 2012 07:55:40 PM UTC  
 
Category: Plotting with OpenGLSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Incorrect Result
Status: FixedAssigned to: Rik <rik5>
Originator Name: Open/Closed: Closed
Release: devOperating System: GNU/Linux

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 Jump to the original submission)

Wed 22 Feb 2012 04:22:06 PM UTC, comment #27:

Drat. Thanks for that spelling correction.

Rik <rik5>
Project AdministratorIn charge of this item.
Wed 22 Feb 2012 01:16:25 PM UTC, comment #26:

I'm surprised I didn't catch the typo when I tested Rik's change. I must have done something wrong when updating.

In any event, I've pushed a fix.

http://hg.savannah.gnu.org/hgweb/octave/rev/1928af0f641b

Ben Abbott <bpabbott>
Project Member
Wed 22 Feb 2012 04:39:37 AM UTC, comment #25:

note that the initial example still does not work:


%> octave -q --no-init-file foo.m
error: `v' undefined near line 154 column 15
error: evaluating argument list element number 1
error: called from:
error: /tmp/octave-3.7/share/octave/3.7.0+/m/plot/private/__fltk_print__.m at line 154, column 3
error: /tmp/octave-3.7/share/octave/3.7.0+/m/plot/print.m at line 395, column 12
error: /tmp/foo.m at line 5, column 1


Muhali <muhali>
Tue 21 Feb 2012 10:05:16 PM UTC, comment #24:

I pushed a changeset (http://hg.savannah.gnu.org/hgweb/octave/rev/6b2448555bbd). Closing this report.

Rik <rik5>
Project AdministratorIn charge of this item.
Tue 21 Feb 2012 07:26:26 PM UTC, comment #23:

Opps !

The "visible", "on" should be removed (it's on inherited by the children).

The corrected version is below.

Ben Abbott <bpabbott>
Project Member
Tue 21 Feb 2012 07:12:53 PM UTC, comment #22:

The GL2PS_BSP_SORT has less trouble with 2D plots than GL2PS_NO_SORT has with 3D. Perhaps the subplot problem can be mitigated by checking that all plots are 2D before switching to GL2PS_NO_SORT ?

Using this changeset, I don't see any problems with any of the plot demos. If we add a subplot demo that includes a 3d mesh and a 2d filled contour, then I expect the 2d filled contour to have problems.

Unless you see a way to use different viewports for different axes, I suggest you push the changeset.

Ben Abbott <bpabbott>
Project Member
Tue 21 Feb 2012 06:05:36 PM UTC, comment #21:

I've made a stab at coding something which switches the gl2ps sort order based on whether the plot is 2D or 3D. It is definitely not final but I want to see what you think.

I fear it will break for subplots where one axis might be 2D and another 3D. I didn't see a quick way to handle that yet.

(file #25101)

Rik <rik5>
Project AdministratorIn charge of this item.
Tue 21 Feb 2012 04:47:28 PM UTC, comment #20:

After looking over the gl2ps docs, my understanding is that a single output stream can have multiple viewports ... Each with independent sorting (one can use GL2PS_BSP_SORT, and another GL2PS_NO_SORT) ?

If so, can gl2ps-renderer.cc/h be rewritten so that each axes has its own viewport.

This would allow 2D axes (where the axes property view(2) == +/- 90) to use GL2PS_NO_SORT, and 3D axes to use GL2PS_BSP_SORT.

Ben Abbott <bpabbott>
Project Member
Tue 21 Feb 2012 02:35:08 AM UTC, comment #19:

After running four sets of demos, the GL2PS_NO_SORT variety produces perfect 2D plots and 3D plots with no hidden line removal.

The GL2PS_BSP_SORT variety produces flawless 3D plots, but doesn't get the order of 2D object correct. The 1st contourf demo is a good example.

The GL2PS_SIMPLE_SORT is only marginally better for 2D plots as compared to GL2PS_BSP_SORT, but still has many problems with ordering of objects.

Changing the zlim property in print.m fixed the problem that initiated this bug report, but other 2D plots still suffer (contourf for example).

Perhaps the gl2ps code needs a patch to avoid changing the sort order of objects with the same depth from the viewer?

Ben Abbott <bpabbott>
Project Member
Tue 21 Feb 2012 02:14:43 AM UTC, comment #18:

I forgot to mention that using GL2PS_SIMPLE_SORT instead of GL2PS_BSP_SORT fixed a lot of problems I see with 2D gl2ps output on MacOS X.

I'm running all the plot demos and saving the results.

I can attach plots for those who are interested.

Ben Abbott <bpabbott>
Project Member
Tue 21 Feb 2012 01:42:06 AM UTC, comment #17:

Rik,

I took a look at gl2ps_renderer.cc. The GL2PS_XXX_SORT is passed as part of gl2psBeginPage (). This is a problem because the choice between GL2PS_BSP_SORT and GL2PS_SIMPLE_SORT needs to be axes specific.

Does this imply that the changeset for pint.m is the proper approach?

Ben Abbott <bpabbott>
Project Member
Mon 20 Feb 2012 09:23:49 PM UTC, comment #16:

Rik, I think either of those solutions will fix the problem.

The only caveat is that it breaks hidden line removal. Take a look at printed output for any the demos for cylinder, ellipsoid, ezmesh, ezsurf, pie3, quiver3, shading, surf, surfc, or trisurf.

It should be sufficient to use GL2PS_BSP_SORT if (abs (view(2)) != 90) and use GL2PS_SIMPLE_SORT or GL2PS_NO_SORT otherwise.

Ben Abbott <bpabbott>
Project Member
Mon 20 Feb 2012 08:17:46 PM UTC, comment #15:

Interestingly, if I switch to GL2PS_NO_SORT it also clears up other Z-stacking related bugs like this one (https://savannah.gnu.org/bugs/?32206) where the colorbar does not appear on top when printing.

Rik <rik5>
Project AdministratorIn charge of this item.
Mon 20 Feb 2012 07:54:03 PM UTC, comment #14:

The patch is very close. It works for objects which are put on the plot, like lines, but the tickmarks on the axes are still obscured because they are at the same Z level as the axis background.

What about changing the object sort ordering used by gl2ps? From the documentation at http://geuz.org/gl2ps/ I see the following for the sort order:

Currently Octave is using GL2PS_BSP_SORT. However, when I set the sort order to GL2PS_NO_SORT, which is for 2-D plots, then everything works correctly. I've attached a simple diff to show what I mean.

If we went this way we could code a test to check for 2D plots and give the correct options to gl2psBeginPage ().

(file #25094)

Rik <rik5>
Project AdministratorIn charge of this item.
Mon 20 Feb 2012 04:41:02 PM UTC, comment #13:

I forgot to restore the zlimmode. Second changeset is attached.

(file #25089)

Ben Abbott <bpabbott>
Project Member
Mon 20 Feb 2012 02:53:12 PM UTC, comment #12:

Now with the changeset attached !

(file #25087)

Ben Abbott <bpabbott>
Project Member
Mon 20 Feb 2012 02:51:43 PM UTC, comment #11:

I think the problem manifests in opengl_renderer::draw_axes_planes in gl-render.cc

For 2D plots, the zlim can be shifted to place the zplane at a location that is further away from the viewer.

I've attached a changset.

Ben Abbott <bpabbott>
Project Member
Mon 20 Feb 2012 01:12:51 PM UTC, comment #10:

saveas() worked like print() did.

I have a faint recollection that I had modified the print() function to behave as Matlab does a few years back. If so this choice was revisited more recently.

We're likely to get complaints either way, but I'm inclined to favor Matlab compatibility ... just because I know how to fix that ;-)

Ben Abbott <bpabbott>
Project Member
Mon 20 Feb 2012 04:07:39 AM UTC, comment #9:

This seems bogus to me. What if the image being produced is for a screen rather than a printer? And there are many color printers available so a color background would be quite feasible.

Maybe Matlab only does this for print? What about the same commands but with saveas?

Rik <rik5>
Project AdministratorIn charge of this item.
Mon 20 Feb 2012 03:32:42 AM UTC, comment #8:

Rik,

Both the axes and the figure backgrounds are white (or "none")

Ben Abbott <bpabbott>
Project Member
Mon 20 Feb 2012 03:11:03 AM UTC, comment #7:

I found a whole thread about the background plot color issue here (http://octave.1599824.n4.nabble.com/color-quot-none-quot-for-figures-td1653194.html).

Ben, you had already noted that Matlab apparently messes with the background color property when printing. I'm wondering what Matlab does for the following.

Does this produces a blue square enclosing a magenta square? Or does it clear the figure color and produce only a magenta square on a white background?

Rik <rik5>
Project AdministratorIn charge of this item.
Sun 19 Feb 2012 11:35:11 PM UTC, comment #6:

As a temporary fix, we could set the color of the axes to "none" during the print process.

I assume the current fltk implementation draws a rectangle with color [1 1 1]. Is there a way to tell OpenGL the background at an infinite distance is colored instead ?

Ben Abbott <bpabbott>
Project Member
Sun 19 Feb 2012 10:48:49 PM UTC, comment #5:

But in my original example there is no difference between line and plot (the latter with 'hold on').

That is, even when using 'plot' I don't see the line and ticks in the figure. I do see them in Ben's example.

Muhali <muhali>
Sun 19 Feb 2012 09:01:10 PM UTC, comment #4:

I took your suggestion and compared the differences between plot() and line() which did immediately reveal the problem. The issue is that when using line() the background color of the plot is set to [1 1 1] or all white. When using plot() the color is 'none' or transparent.

This doesn't seem to be a problem with the OpenGL renderer for the screen because the Z-order stacking is correct, i.e., the stacking is background at bottom, axis ticks on top of that, lines and any other objects at top of stack.

When printing, however, the background of the plot is placed on top of most of the other objects and hides the the tick marks and any line objects.

Sample code:

Rik <rik5>
Project AdministratorIn charge of this item.
Sat 18 Feb 2012 11:46:22 PM UTC, comment #3:

What surprises me is that if line() is replaced by plot(), then then the output is correct.

Either way, it does look like a gl2ps bug. Perhaps isolating the difference in the object properties resulting from line() and plot() can help isolate the bug.

Ben Abbott <bpabbott>
Project Member
Sat 18 Feb 2012 10:17:08 PM UTC, comment #2:

The problem may lie in gl2ps.c. I used the following to get the raw PostScript output

This prints things to the screen as well but you can ignore that. Using a PostScript viewer shows that the output is already incorrect at this stage.

Rik <rik5>
Project AdministratorIn charge of this item.
Fri 17 Feb 2012 11:40:03 PM UTC, comment #1:

I see the line in the plot you attached. However, I don't see the line in the plot foo.png produced when I run the script you provided.

In both cases, the tick marks are missing.

I have no idea what is wrong here. I was suspicious that the changeset below caused the problem, but I checked a prior build and encountered the same problem.

http://hg.savannah.gnu.org/hgweb/octave/rev/81183cd6eaae

I tried the modified script below

It behaves the same as Mhuali's.

If the function is changed to plot (func=@plot), then everything behaves as expected.

This suggests the problem is with _line_.m and might be discovered by comparing to _plt_.m

Ben Abbott <bpabbott>
Project Member
Fri 17 Feb 2012 07:55:40 PM UTC, original submission:

From this

I get the attached figure. Obviously the line and the ticks are missing.

Muhali <muhali>

 

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

Attach File(s):
   
   
Comment:
   

Attached Files
file #25101:  gl2ps_cset1.diff added by rik5 (1KiB - text/x-patch)
file #25094:  gl2ps-renderer.diff added by rik5 (659B - text/x-patch)
file #25089:  changeset.patch added by bpabbott (2KiB - application/octet-stream - 2nd changeset)
file #25087:  changeset.patch added by bpabbott (1KiB - application/octet-stream - first changeset)
file #25076:  foo.png added by muhali (15KiB - image/png)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by rik5 (Posted a comment)
  • -unavailable- added by bpabbott (Posted a comment)
  • -unavailable- added by jordigh (Updated the item)
  • -unavailable- added by muhali (Submitted the item)
  •  

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

    Only project members can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 13 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Tue 21 Feb 2012 10:05:16 PM UTCrik5StatusConfirmed=>Fixed
      Open/ClosedOpen=>Closed
    Tue 21 Feb 2012 07:12:53 PM UTCbpabbottAssigned tobpabbott=>rik5
    Tue 21 Feb 2012 06:05:36 PM UTCrik5Attached File-=>Added gl2ps_cset1.diff, #25101
    Tue 21 Feb 2012 04:47:28 PM UTCbpabbottStatusReady For Test=>Confirmed
    Mon 20 Feb 2012 07:54:03 PM UTCrik5Attached File-=>Added gl2ps-renderer.diff, #25094
    Mon 20 Feb 2012 04:41:02 PM UTCbpabbottAttached File-=>Added changeset.patch, #25089
    Mon 20 Feb 2012 02:53:12 PM UTCbpabbottAttached File-=>Added changeset.patch, #25087
    Mon 20 Feb 2012 02:51:43 PM UTCbpabbottStatusConfirmed=>Ready For Test
      Assigned toNone=>bpabbott
    Fri 17 Feb 2012 11:40:03 PM UTCbpabbottItem GroupNone=>Incorrect Result
    Fri 17 Feb 2012 08:06:10 PM UTCjordighStatusNone=>Confirmed
    Fri 17 Feb 2012 07:55:40 PM UTCmuhaliAttached File-=>Added foo.png, #25076

    Back to the top


    Powered by Savane 3.1-cleanup1