Closed hageldave closed 1 year ago
I tried it again and it also seems to have problems with very small ranges, when both values are small (xlow = 0.0, xhigh = 4.5e-7). Update 1: Seems to be working fine with OpenGL Backend, so probably only an issue with fallback rendering.
Update 2: The problem seems to be the g.draw(new Line2D.Double(x1, y1, x2, y2));
call in the LinesRenderer's renderFallbackLinesCT() method (and maybe also the renderFallbackLinesVT() method). The rendering seems to be fast, if this command is commented out.
Update 3: When switching x/y coords in the .draw() call, it works fine (with intersection check disabled).
so we identified the problem to be in fallback line rendering, specifically this line: https://github.com/hageldave/JPlotter/blob/9af3be4189e3426238b246be27c1588912e6cd99/jplotter/src/main/java/hageldave/jplotter/renderers/LinesRenderer.java#L527 when zoomed a lot, a segments x,y coordinates can be huge (e.g. x=10^8) and we suspect this to be the problem.
The solution is to test if the segment is very long (len>100.000
) and if that is the case, we calculate the intersection of the segment with the view rectangle, and use the intersection coordinates instead of the segment start and end coordinates.
There may be some things to be taken care of, e.g. gradient paint (color interpolation for the new segment coords) and maybe stroke pattern arguments need to be adapted.
Extended wilkinson struggles to compute good ticks (takes very long) when the range of values is very small (e.g. xhigh-xlow < 1e-8) but values are large (e.g. xlow > 10.000).