Strange behavior in overlay painting from zoom 2 down to 0

[ulixit]

Hi,
also from me, first of all, thanks for the great library.

I noticed a strange behavior in overlay painting when zoom level drops from 3 to 2 and then down to 1 and 0.
To evidence this strange thing put these lines in example 4, FancyWaypointRenderer.java just near the end of paintWaypoint(...), right before g.dispose(). Recompile and run.

Concentric circles paints well until zoom 3. From zoom 2 down they are no longer concentric.

// paints a blue circle with an internal white circle
g.setColor(Color.BLUE);
g.fillOval(x-7, y-7, 14, 14);
g.setColor(Color.WHITE);
g.fillOval(x-4, y-4, 8, 8);
System.out.println("zoom"+viewer.getZoom());

This was with openjdk 11.0.11 on Raspbian

[msteiger]

Thanks, I will try to reproduce the error.

[msteiger]

Sorry for the long delay. I am able to reproduce the problem and will debug it a bit. Maybe I can find something... in the
meantime, did find anything related to the problem?

[ulixit]

Yes. After some more attempts I recently found a possible problem with Graphics2D.translate(...) which is presumably called somewhere before paintWaypoint(...)
By replacing my previous sample code with this following the problem disappears:

// paints a blue circle with an internal white circle
Rectangle rect = viewer.getViewportBounds(); // added
g.translate(rect.x, rect.y);                 // added to undo g.translate(-rect.x, -rect.y) called elsewhere 
g.setColor(Color.BLUE);
g.fillOval(x-7-rect.x, y-7-rect.y, 14, 14);  // changed
g.setColor(Color.WHITE);
g.fillOval(x-4-rect.x, y-4-rect.y, 8, 8);    // changed
System.out.println("zoom"+viewer.getZoom());

[javagl]

There is

debugging

and there is

^debugging

The first one refers to the process of diligently and systematically analyzing a flaw (preferably not in your own code), in order to solve the problem.

The latter refers to things of which you'd hesitate to admit publicly that you have done them (and that may be fueled by some geeky curiosity, and may not even lead to a solution).

When inserting the following _debugging statements in the FancyWaypointRenderer

        try {
            System.out.println("graphics: "+g);
            sun.java2d.SunGraphics2D sg = (SunGraphics2D) g;

            sun.java2d.pipe.PixelToShapeConverter sunGraphicsFillPipe = (PixelToShapeConverter) sg.fillpipe;
            System.out.println("graphics.fillPipe: "+sunGraphicsFillPipe);

            Field f = Class.forName("sun.java2d.pipe.PixelToShapeConverter").getDeclaredField("outpipe");
            f.setAccessible(true);
            Object pixelToShapeConverterOutpipe = f.get(sunGraphicsFillPipe);
            System.out.println("pixelToShapeConverter.outpipe: "+pixelToShapeConverterOutpipe);
            
        } catch (Exception e) {
            e.printStackTrace();
        }

(which may not even work in the newer Java versions, with all this "module sealing" and such...), then the output may be something like

graphics: sun.java2d.SunGraphics2D[font=javax.swing.plaf.FontUIResource[family=Dialog,name=Dialog,style=plain,size=12],color=sun.swing.PrintColorUIResource[r=51,g=51,b=51]]
graphics.fillPipe: sun.java2d.pipe.PixelToParallelogramConverter@e9940ac
pixelToShapeConverter.outpipe: sun.java2d.pipe.PixelToParallelogramConverter@3429e7aa

Looking at the code of PixelToShapeConverter#fillOval, it reveals...

    public void fillOval(SunGraphics2D sg,
                         int x, int y, int w, int h) {
        outpipe.fill(sg, new Ellipse2D.Float(x, y, w, h));
    }

Now. There's that Float. And I'm reasonably sure that this is the culprit. The translation (when fully zoomed in) is 17586168, and in the single-precision floating-point world, adding 1 to that will yield ... 17586168, i.e. the same value. You're hitting the limit of float here.

The solution... might be... well, ... handwavingly: to carry this translation, in an "un-applied form", until shortly before it is supposed to be used for rendering, then do the computations (in double) that are required to bring that into the pixel space, and draw these pixels where they should be.

---

An aside: I noticed that when changing

    g.fillOval(x-7, y-7, 14, 14);

to

    g.fill(new Ellipse2D.Double(x-7, x-7, 14, 14));

then the ellipses are drawn at the wrong place, and I haven't figured out why. It seems like it's flipped vertically or so.

An aside to the aside:

Similar pixel-artifacts still appear with Ellipse2D.Double. I just thought that this might be an easy solution/workaround, but ... it isn't, becasue the problem is deeper.

[msteiger]

Wow, impressive research, thanks a lot!