cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Choose Language Hide Translation Bar
0 Kudos

Fix display-engine regression from JMP12

What inspired this wish list request? It is my understanding that advancing build numbers should not come with feature regression, yet that is exactly what has happened since JMP12. (I haven't tested JMP13).  Starting with JMP14, the display of markers and SVG strings within a FrameBox has two serious regressions

 

 

What is the improvement you would like to see? Fix the regressions please.

 

 

Why is this idea important? ... this is obvious

 

Here is the crux -- the display order of drawn elements in the FrameBox MUST FOLLOW THE GIVEN DRAWING ORDER.  I am not the first one to bring this up and I will not be the last.  Please Please PLEASE JMP devs -- fix the display order BS.  If I draw an element above a MarkerSeg -- then that marker seg SHOULD NOT BE DRAWN ABOVE THE ELEMENT.  I have brought this up several times over the past two years and I've seen other people bring it up as well.  Why the silence?  This should be an easy fix.

 

And secondly, in JMP12, SVG strings were properly aliased.  In JMP14 and beyond (even JMP17), the SVG strings are not aliased properly and introduce visual bugs.  This can be important when quickly scanning graphs for anything unusual -- the SVG strings are background markers and shouldn't provide visual chaos, yet there is no way around it since JMP12 due to this regression.

 

Here is some code showing the issue with MarkerSeg drawing order:

Names Default to Here( 1 );
table = New Table( "test table",
	Add Rows( 150000 ),
	<<New Column( "X", "Numeric", <<Set Each Value( Random Normal() ) ),
	<<New Column( "Y", "Numeric", <<Set Each Value( Random Normal() ) )
);
Eval( Eval Expr(
New Window( "Test",
	<<On Close( Close( Expr( table ), No Save ) )
,
	Platform( table,
		ob = Outline Box( "",
			Bivariate(
				X( :x ),
				Y( :y )
			)
		)
	)
);
) );
(ob[Frame Box( 1 )] << Find Seg( Marker Seg( 1 ) )) << Set Transparency( 0.4 );
ob[Frame Box( 1 )] << Add Graphics Script(
	"FAKE_LINE_OF_FIT";
	Pen Color( "Black" );
	Pen Size( 4 );
	Line( [-5, 5], [-5, 5] );
	Pen Color( "Red" );
	Pen Size( 3 );
	Line( [-5, 5], [-5, 5] );
);

JMP16:

ErraticAttack_1-1685489019001.png

 

JMP12 (marker segs are drawn FIRST)

ErraticAttack_2-1685489055438.png

 

And here is an example of the aliasing issue (the background grid is a regular grid of lines):

JMP16:

ErraticAttack_5-1685489128427.png

 

JMP12 (aliased properly!):

ErraticAttack_6-1685489139728.png

 

 

 

 

 

 

 

5 Comments
SamGardner
Staff
Status changed to: New

@ErraticAttack this is a the type of issue that is better addressed by contacting JMP Technical Support.  I encourage you to send this to support@jmp.com and they can investigate the issue you have identified.  Thanks.  

XanGregg
Staff

Thanks for the report, @ErraticAttack. If it's any consolation, there was an intentional change to make sure selected markers are drawn on top of other content. However, I can see your point that you may want a custom graphics script to be always on top, and JMP should support that.

I haven't been able to reproduce the anti-aliasing issue with SVG, but there are many ways of creating and exporting gridlines, and I'm likely doing something different than you are. I tried built-in gridlines and custom gridlines from the below script. Then I exported with File > Export > Image > SVG and viewed in Edge and Chrome.

Names Default To Here( 1 );
Open( "$SAMPLE_DATA/Big Class.jmp" );
biv = Bivariate( Y( :weight ), X( :height ), FitLine );
rbiv = biv << report;
framebox = rbiv[frame box( 1 )];
framebox << Add Graphics Script(
       Pen Color( [1 1 1] * 0.5 );
       for (x = x origin(), x < x origin() + x range(), x += 1/2,
              vline(x);
       );
       for (y = y origin(), y < y origin() + y range(), y += 2,
              hline(y);
       );
);

 

ErraticAttack
Level VI

@XanGregg , Thanks for the response!  I was thinking that the Marker issue was due to JMP12 and prior sometimes obscuring selected points behind unselected points.  It is good to show them of course, just not above all other elements.

 

As for the aliasing issue -- the issue is adding an SVG path to a FrameBox. I guess it's not exactly a regular grid of lines -- it's a regular grid of boxes (representing die on a wafermap, and of course the space in between -- the scribes).

here is an example showing the issue:

Names Default to Here( 1 );

reticle x = 30;
reticle y = 30;
x stepping = 5;
y stepping = 5;
x size = 4.9;
y size = 4.9;

reticle x0 = 0;
reticle y0 = 0;

x start = {};
y start = {};
x end = {};
y end = {};

Summation( x = 0, 5,
	Summation( y = 0, 5,
		Insert Into( x start, x * x stepping + 0.1 );
		Insert Into( x end, (x + 1) * x stepping );
		Insert Into( y start, y * y stepping );
		Insert Into( y end, (y + 1) * y stepping - 0.1 );
		0
	);
	0
);
reticle path = {};
Summation( i = 1, N Items( x start ),
	Insert Into( reticle path,
		Eval Insert( "	m^xstart[i]^,^ystart[i]^ h^(xend[i]-xstart[i])^ v^(yend[i]-ystart[i])^ h^-(xend[i]-xstart[i])^ z m^-xstart[i]^,^-ystart[i]^" );
	);
	0
);

reticle path = Concat Items( reticle path, "\!N" );
path = "";

reticle grid = 5;

For( x = -reticle grid, x <= reticle grid, x++,
	For( y = -reticle grid, y <= reticle grid, y++,
		path ||= "\!NM" || Char( x * (reticle x - reticle x0) ) || "," || Char( y * (reticle y - reticle y0 ) ) || " " || reticle path
	)
);

Eval( Eval Expr(
New Window( "Test",
	<<Show Menu( 0 ),
	<<Show Toolbars( 0 ),
	Graph Box(
		Frame Size( 300, 300 ),
		X Scale( -160, 160 ),
		Y Scale( -160, 160 ),
		Suppress Axes,
		Path( Expr( path ) );
		Fill Color( "White" );
		Path(
			"M0,-150 a150,150 0 0,0 -150,150 a150,150 0 1,0 150,-150 v-100 a500,500 0 0,0 -500,500 a500,500 0 1,0 500,-500 z",
			1
		);
		Pen Color( {0.75, 0.75, 0.75} );
		Pen Size( 1 ) ;
		Path( "M0,-150 a150,150 0 0,0 -150,150 a150,150 0 1,0 150,-150 z" );
		0;
	)
)
) )

This is the result I get on JMP17.0.  Not only are there superfluous thick lines visually appearing, but the individual squares are not consistently sized.  This is the type of display issues that happens when no anti-aliasing is performed.  I don't have JMP12 installed on my machine any more, 

ErraticAttack_0-1685696920551.png

Here's the same script in JMP12:

ErraticAttack_1-1685698151665.png

it's not fully perfect, but certainly much better.

 

Thanks for your time!!

XanGregg
Staff

 

Thanks, I can see the issue now. It looks like our Windows drawing layer is making an "optimization" and turning off anti-aliasing when all the path segments are rectilinear. I don't know the details, but I think part of it is avoiding fuzzy rectilinear lines. So one hack would be to insert a small diagonal line into you path, such as "m0,0 l0.01,0.01". Then JMP 17 will behave like JMP 12.

 

However, I notice your graph is size 300 and the scale spans -160 to 160. If you can make the graph size 320, both 12 and 17 will look better since the anti-aliasing is not needed (+/-1 pixel maybe).

 

JMP 12: 300 vs 320

XanGregg_0-1685713630631.png

JMP 17: 300 vs 320

XanGregg_1-1685715366316.png

 

 

ErraticAttack
Level VI

Thank you so much for that hack / fix!!!  I am displaying many different wafermaps with die of various sizes, and many wafers have multiple die sizes per reticle -- not really possible to line it up beforehand to the size of the display box.  However, adding the non-rectilinear element to the graph to activate the anti-aliasing works like a charm!  

 

Thank you very much -- this makes me very happy.