piccolo2d / piccolo2d.java

Structured 2D Graphics Framework
http://piccolo2d.org
Other
51 stars 14 forks source link

PCanvas.setCamera() sets new Camera's bounds to Canvas bounds #227

Closed mro closed 9 years ago

mro commented 9 years ago

Originally reported on Google Code with ID 227

Consider this code that replaces the camera on a PCanvas:

PCanvas canvas = new PCanvas();
PCamera camera = PUtil.createBasicScenegraph();
canvas.setCamera(camera); //*
canvas.setPanEventHandler(new PPanEventHandler());
canvas.setZoomEventHandler(new PZoomEventHandler());

The new camera's bounds are set by the PCanvas.setCamera() method to be the bounds
of the PCanvas. If PCanvas is a component of some JComponent, J, it may have bounds
with (x,y) not equal to (0,0) (if J's layout manager repositions it.)

This seems to be undesirable behavior. (In a simple scenegraph the side effect is that
after replacing the camera the camera renders the layer starting at some offset (whatever
the PCanvas's (x,y) offset is)).

It seems that PCanvas.setCamera() should the camera's bounds to be (0,0,canvas.width,canvas.height).

(Easy workaround: just set the camera's bounds yourself after replacing the camera.)

Reported by atdixon on 2011-10-29 00:52:12

mro commented 9 years ago
Sounds like a bug to me, want to code a fix?

Reported by heuermh on 2011-11-01 19:43:45

mro commented 9 years ago
Sure, I'll put some thought into it.

Also wondering if PCanvas.setBounds() is correct wrt to the bounds it sets on the camera:

    public void setBounds(final int x, final int y, final int width, final int height)
{
        camera.setBounds(camera.getX(), camera.getY(), width, height);
        super.setBounds(x, y, width, height);
    }

I suppose the fundamental question is, in what cases do clients want the canvas's camera
to NOT be at (0,0)? Do you know any such use cases?

Reported by atdixon on 2011-11-02 02:01:23

mro commented 9 years ago
Committed revision 1155.

Reported by atdixon on 2011-11-13 19:01:27

mro commented 9 years ago
Committed revision 1156. (TRUNK, same fix as the earlier branch commit.)

Reported by atdixon on 2011-11-13 19:12:46

mro commented 9 years ago

Reported by heuermh on 2013-11-26 20:47:09