fenfire-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Fenfire-dev] Proposed change to VobCoorder.RenderInfo


From: Benja Fallenstein
Subject: [Fenfire-dev] Proposed change to VobCoorder.RenderInfo
Date: Sat, 03 Jul 2004 02:25:03 +0200
User-agent: Mozilla Thunderbird 0.6 (X11/20040605)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

In address@hidden, I've changed Vob.RenderInfo to the
following interface:

|   public static abstract class RenderInfo extends java.awt.Rectangle {
|       public float scaleX, scaleY;
|
|       /**The background color of the canvas where we're being drawn.
|        *               What about background images?!?
|        */
|       public abstract Color getBgColor();
|
|       public abstract void xform(float x, float y, Point into);
|       public abstract void xform_horiz(float x, float y, Point into);
|       public abstract void xform_vert(float x, float y, Point into);
|
|       /** Perform the inverse transformation, if possible.
|        * Into the (-1..1, -1..1) cs
|        */
|       public abstract void invert(float xs, float ys, float[] xyout);
|   }

Before, to get the rectangle to draw itself into, a vob would have to
use the following pattern:

|    Rectangle rect = new Rectangle();
|
|    public void render(...Vob.RenderInfo info1...) {
|        info1.getExtRect(rect);
|        // draw something using rect.x, rect.y,
|        // rect.width, rect.height
|    }

With the proposed change, this can change to:

|    public void render(...Vob.RenderInfo info1...) {
|        // draw something using info1.x, info1.y,
|        // info1.width, info1.height
|    }

I also removed getMixedFgColor(), because it wasn't really used
usefully, and the commented out getMixedBgFract(), and added scaleX and
scaleY. The latter two tell the vob how much it is stretched in X- and
Y-direction; this can be used, for example, to draw a stretched
rectangle correctly.

Currently there is a method VobCoorder.getRenderInfo(cs). I think that
should be removed, since there is VobCoorder.transformPoints3 and
VobCoorder.inverseTransformPoints3, which is used when this information
is needed at all. Note that GLVobCoorder does not have a correct
implementation of RenderInfo -- it uses the orthogonal AWT one.

After this change, RenderInfo would only be used in AWT, in Vob.render()
(the method AWT uses to draw a vob on the screen). AWT, at least the
basic AWT we're using, only supports translations and scaling, no
rotations etc. Thus xform() etc. are only convenience functions: all the
information is provided by the (x,y,width,height,scaleX,scaleY).

I think that then, they should be replaced by the following two methods:

|    public int x(float px) { return (int)(x + scaleX*px); }
|    public int y(float py) { return (int)(y + scaleY*py); }

which transform an x-coordinate and a y-coordinate, respectively.

Then, we don't need to write

|    Point pt = new Point();
|
|    public void render(...) {
|        info1.xform(x0, y0, pt);
|        // do something with pt.x, pt.y
|    }

but we can instead write

|    public void render(...) {
|        float x = info1.x(x0), y = info1.y(y0);
|        // do something with x, y
|    }

which is cleaner, because we don't need the Point object outside the method.

I also think that the inverse() function, which then is a pure
convenience function, isn't really needed and can be removed.

If you think these changes are bad, please speak up. I'll reverse the
changes I've made already, if necessary.

Cheers,
- - Benja
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFA5fzfUvR5J6wSKPMRAgS6AKCttjokTkZZ/70lbPGQXmyRnaLR7ACeNxNR
/BwEtdwdp9yItf5RAfxVZxU=
=woAG
-----END PGP SIGNATURE-----




reply via email to

[Prev in Thread] Current Thread [Next in Thread]