next »

[Mathias 'cylab' Henze]

I am currently correcting the ray-triangle intersection code in openmali and noticed the following code block:

Code:

    /*
     * static final fields that are reused for computations, so the
     * computations don't tax the garbage collector
     */
    private static final Point3f  tmpPnt  = new Point3f();
    private static final Matrix3f tmpMat  = new Matrix3f();
    private static final Vector3f tmpVec1 = new Vector3f();
    private static final Vector3f tmpVec2 = new Vector3f();
    private static final Vector3f tmpVec3 = new Vector3f();
    private static final Vector3f tmpVec4 = new Vector3f();
    private static final Vector3f tmpVec5 = new Vector3f();
    private static final Vector3f tmpVec6 = new Vector3f();

This is very problematic to me, because it makes the whole Triangle class non-thread-safe - regardless of different instances. While I consider it ok to have a non-thread-safe scene graph, I consider it a no go to have a non-thread-safe math library, since it prevents off render thread computations.

I will change the Triangle class to object pooling.

What do you think? Do you know of other such use cases in openmali?

[Marvin Fröhlich]

While I consider it ok to have a non-thread-safe scene graph, I consider it a no go to have a non-thread-safe math library, since it prevents off render thread computations.

I will change the Triangle class to object pooling.

What do you think?

Go ahead and change that. Should be no problem.

Do you know of other such use cases in openmali?

vecmath2 is designed to produce no garbage collection at the (possible) cost of thread-safety. So I guess, vecmath2 is not thread safe as a whole. Though there shouldn't be too many cases, where static helper instances are used like above.

Marvin

[Mathias 'cylab' Henze]

As long as only the instances aren't thread safe, I think it is ok, when documented.