Fri 26 Aug 2016 06:02:12 PM UTC, comment #13:
Lowering the expected file size fixed the issue to me.
|
Thu 25 Aug 2016 03:51:24 PM UTC, comment #12:
I changed the fingerprint in the test (http://hg.savannah.gnu.org/hgweb/octave/rev/85fa7238dafc). See if it works for you now.
|
Thu 25 Aug 2016 03:22:01 PM UTC, comment #11:
According to doug on IRC, the cset 8f23b5b23235 is causing one of the tests to fail. Me and jwe are also seeing this test failing.
I guess that since the figure has changed, the filesize has changed as well. But is the expected file size that should be changed? I guess the test was not failing for you so maybe it should be the precision on the file size?
|
Mon 22 Aug 2016 08:39:14 PM UTC, comment #10:
@Pantxo: I pushed your cest for grid/axes overlap here (http://hg.savannah.gnu.org/hgweb/octave/rev/8f23b5b23235). I will push another one to fix the fact that all lines that are part of the axes do not respect the linewidth property of the axes object.
|
Mon 22 Aug 2016 05:35:34 PM UTC, comment #9:
Another comment, when zooming in on the pdf, I can see that the axes box is drawn with a linewidth of 0.5 (as is specified in the axes), but the grid is drawn with a linewidth of 1.0. It is "showing" through because of that.
Should the grid linewidth be the same as other lines set in the axes? I'll ask on the Maintainer's List.
|
Mon 22 Aug 2016 05:30:53 PM UTC, comment #8:
The second patch works for me with both FLTK and Qt toolkits. I'm tempted to push it, but are we concerned with the anti-aliasing effects during printing? I'm attaching the file that results when I print to pdf.
(file #38316)
|
Mon 22 Aug 2016 11:43:04 AM UTC, comment #7:
I don't see a difference between fltk and qt on my system but anyway following the logic of the previous cset I should have drawn the planes first. I attached an updated cset, but this way of ordering primitives doesn't seem robust.
(file #38312)
|
Mon 22 Aug 2016 12:51:24 AM UTC, comment #6:
@Pantxo's patch works for me with the Qt toolkit. With the FLTK toolkit, no grid is displayed. It seems to still be behind the axes planes.
This is annoying, but maybe the draw_axes_plane routine needs to be broken up. It can use a GL_PATH or GL_QUADS to produce the colored background. And then a separate function which uses GL_LINES or GL_LINE_LOOP to draw the outline part of the axes. The outline part could be called after the grid has been drawn.
This would probably also be helpful for supporting the 'origin' specification for xaxislocation and yaxislocation.
|
Sun 21 Aug 2016 08:55:23 PM UTC, comment #5:
@Dan: the artifact you see is antialiasing (that was applied by ghostscript when converting eps to raster image) which leads to blending/blurring two overlapping lines.
I played with simply inverting the order in which we draw axes parts (see also bug #46073): in the attached cset I draw the grid, the tick marks and then only the axes box. The on-screen result is as expected. The png printout is also affected by antialiasing issues but at least the blue is over the red.
Ideally we should avoid overlapping lines but it is not straightforward as explained by Rik in bug #46073.
(file #38308)
|
Sun 21 Aug 2016 05:22:15 PM UTC, comment #4:
Oh, you used "print -dpng myfile.png". Yes, I'm getting the same result that way. It looks to me that OSMesa doesn't have alpha blending. We know there is something odd with line order as well--wasn't there a bug in which two overlying octagon patches or decagon patches had the border of the further behind patch out in front?
|
Sun 21 Aug 2016 05:19:33 PM UTC, comment #3:
Rik,
On your octave plot, the axis color is different
shade of red than the grid.
So may be the issue is with transparency level.
Perhaps a different color combinations could make it more
pronounced.
(On all my computers the plots look exactly like Dan's).
Dmitri.
--
|
Sun 21 Aug 2016 04:50:54 PM UTC, comment #2:
Hmmm. Might be different OpenGL versions, Mesa versions, etc. That doesn't sound fun o debug.
|
Sun 21 Aug 2016 03:41:31 PM UTC, comment #1:
Attached is the plot generated on my system for the Qt toolkit. It looks close to Matlab result. However, exact-match purists would say defaulting to 0 left-x-range and consequently spacing by 2 rather than 1 is a bug.
(file #38302)
|
Sun 21 Aug 2016 02:54:08 PM UTC, original submission:
If the grid is on and the box is displayed, then the grid "wins" and is displayed instead of the box. Matlab does it correctly and displays the box/axes color.
Sample script:
Attached are an image from Octave and one from Matlab.
|