Vob2D.render() parameters

["B. Fallenstein" <b.fallenstein@xxxxxx>]

From Vob2D:
>    abstract public void render(java.awt.Graphics g, 
>                                int x, int y, int w, int h,
>                                java.awt.Color bg, float bgFract,
>                                boolean boxDrawn,
>                                boolean fast);

>     * XXX Too many params?

Too many params, indeed. Because we may want to get rid of some of them,
or introduce new ones, which would require changing all Vob2D objects.
Because we may want to call other methods with the same information,
e.g. so as not to lump too much into the render() function of a vob.
This leads to highly unreadable and even less maintainable method calls,
all of which must be updated when the standard render() method is changed.

What about this:
    abstract public void render(java.awt.Graphics g, RenderingInfo2D i);

The RenderingInfo2D would contain all the informations above. It would
be a final, but mutable object created and changed by the VobSet. Only
one RenderingInfo2D would need to be created each time the vobset is
rendered... or maybe it can even be cached between renderings.

Additionally to the information given above, it should contain:
* The Graphics object again (calling render() with it directly is just convenience);
* The top-level Graphics object (without any translations, rotations
etc. done);
* The coordinates of the vob's center, in the top-level Graphics object
(to draw connections);
* The Vob2D, in case this is passed on to other classes;
* Both the top-level vob set and the vob set this vob is in.

If we need more information in the future, it'll suffice to change
RenderingInfo2D and the vob sets; we don't need to change _all_ vobs as well.

----

Connector2D: I've come to think that Decorator2D *would* be a better
name for it. It should be called rather like the vobs:
    abstract public void renderDecor(Graphics g, Vob2D v, RenderingInfo i);

The reason to call it Decorator is that it never draws a whole
connection-- it only draws the half of a connection attached to a
specific vob. Now, that means the class can be used just as well to do
other kinds of decorations of vobs-- e.g., a "lock" symbol next to a
cell vob of a cell that can't be edited, or a "link" symbol next to a
cursor cell. Decorator2D would be an easy way to handle these
efficiently, too-- and with the right behaviour: if they're interpolated
at all, they should be interpolated together with the vob.

(Maybe it should be VobDecorator2D?)

I still need to figure out an efficient way to sort the decorations like
the vobs in the corresponding vob set. Depth sorting will actually not
suffice, because we want to draw e.g. beams between the box background
and the content (text); thus this kind of decoration needs to be drawn
individually for each vob, after the background, but before the content.

- Benja