next »

[Patheros]

First is there any reason all the fields of Appearance are nulled out at the start. If not then this shouldn't be the VM initializes all fields automatically so reinitializing them to the defaults can be a waste of time.

Second what does it mean for an Appearance to have a null Material (just to use Martial as an example)?

For example I have RectBillboards and TextRectangle which after they are created have no Material. I want to alter there emissive light. When I go to change the Materials I find them null. But when i set them to a new Material(), they don't show up.

[Marvin Fröhlich]

First is there any reason all the fields of Appearance are nulled out at the start. If not then this shouldn't be the VM initializes all fields automatically so reinitializing them to the defaults can be a waste of time.

Second what does it mean for an Appearance to have a null Material (just to use Martial as an example)?

For example I have RectBillboards and TextRectangle which after they are created have no Material. I want to alter there emissive light. When I go to change the Materials I find them null. But when i set them to a new Material(), they don't show up.

Having null values for things like Material makes the Renderer take a certain default internal representation for the Material.

Marvin

['n ddrylliog]

If there were non-null, for objects with a default appearance, it would be a waste of memory (and thus, GC time when objects are trashed).

You pretty never use *every single attribute* in the Appearance class (e.g. you don't need lighting ? you don't need Material but ColoringAttributes instead). So it's OK to have the ones you don't use as null.

[Patheros]

Ok. Null fields means use default, thats what I thought.

However I seemed to not have conveyed my first point well enough.

for a field in a class

Code:

Object obj = null;

can be slower than

Code:

Object obj;

because in the first cases the JVM will allocate them memory for the object, then set it to null. then (possibly) set set it to null again because you explicitly stated it

in the second case the JVM will allocate the memory for the object then set it to null.

[Marvin Fröhlich]

Code:

Object obj = null;

Of course this is slower than

Code:

Object obj;

Because the variable is initialized twice. Only to the first, if you need to. But the difference shouldn't be too big.

The second one doesn't allocate memory. In Java only pointers are used. So the memory (ignoring the memory for the pointer) is only allocated when the pointer is set to an instance.

Marvin

[horati]

And with optimizations turned on,

Object obj = null

should be ignored.  Even without optimizations, the 1-3 machine cycles to do the assignment isn't going to be that painful on modern computers even if you do it a few hundred thousand times, especially since the separate &addr=0 assignments should all exist on the same memory page as well as be pipelined on the cpu resulting in O(1) performance for each class in the object's hierarchy, possibly O(1) per object.

Regardless, it's always better to code for maintainability and clarity until performance has been proven to be a problem.

Even if I'm wrong in some piece of my logic there (my understanding of JVM internals far outstrips my understanding of 3D mechanics) and all the assignments occur, 1 million needless assignments that are not pipelined or cached each requiring 3 cycles on a machine running 3 billion cycles per second results in a waste of 0.00033333 seconds.  Other factors such as incorrect array size allocation, memory fragmentation, and poor localization resulting in lots of L2 cache swapping have WAY more impact.

[Patheros]

Ok, i just shut up about the redundant assignments.

Another question... What if Appearance its self is null? Does it follow the same design? That is: Does it use a default Appearance?

['n ddrylliog]

Ok, i just shut up about the redundant assignments.
Another question... What if Appearance its self is null? Does it follow the same design? That is: Does it use a default Appearance?

Yeah.

[Patheros]

Wouldn't it be useful to have a getAndInitX() (or something like that) so you can to do

Code:

Apperance a = shape3D.getApperance();
a.getAndInitMaterial().getEmissiveColor().set(1f,0f,0f)

rather than

Code:

Apperance a = shape3D.getApperance();
if(a.getMaterial() == null) a.setMaterial(new Material());
a.getAndInitMaterial().getEmissiveColor().set(1f,0f,0f)

[horati]

Sounds like a great addition to an AppearanceHelper class rather than Appearance itself.  AppearanceHelper.supplyMaterial( appearance ) is descriptive and reduces bloat of the underlying class.

[Marvin Fröhlich]

This is already done for the getAppearance() method in Shape3D. It is overloaded. The second implementation with a boolean parameter creates a new Appearance instance, if it is true and if it isn't already initialized fore it returns the current instance.

I could do that for the Appearance internals, too.

Marvin

['n ddrylliog]

Note : I've since long added several methods like setColor() which creates XXXXXXXXAttributes needed.. Please check them out.

[Patheros]

First

This is already done for the getAppearance() method in Shape3D. It is overloaded. The second implementation with a boolean parameter creates a new Appearance instance, if it is true and if it isn't already initialized fore it returns the current instance.

I see this now and will definitely use it when I next update my projects current Xith jars.

Are there plans to deprecating the non overwritten methods? Or perhaps changing them (getAperrance() to act like getAperrance(true) rather than getAperrance(false) I would imagine that the majority of the use of use of getApperance()/getAperrance(false) is inside of the rendering code.

Second

I could do that for the Appearance internals, too.

Sounds like a great addition to an AppearanceHelper class rather than Appearance itself.  AppearanceHelper.supplyMaterial( appearance ) is descriptive and reduces bloat of the underlying class.

I think the methods should go in Appearance itself and I think they should follow the existing method of overloading with a boolean.

Third

Note : I've since long added several methods like setColor() which creates XXXXXXXXAttributes needed.. Please check them out.

These are help full methods, but they are limited in scope. For example there are no methods to get at the Material. However I would not suggest adding such methods. I think doing so would just further inter connect Appearance and its field classes (such as Material)

['n ddrylliog]

Note : I've since long added several methods like setColor() which creates XXXXXXXXAttributes needed.. Please check them out.

These are help full methods, but they are limited in scope. For example there are no methods to get at the Material. However I would not suggest adding such methods. I think doing so would just further inter connect Appearance and its field classes (such as Material)

Yeah, getAppearance(true) deprecates these methods..

[Marvin Fröhlich]

First
Are there plans to deprecating the non overwritten methods? Or perhaps changing them (getAperrance() to act like getAperrance(true) rather than getAperrance(false) I would imagine that the majority of the use of use of getApperance()/getAperrance(false) is inside of the rendering code.

This is not possible. In many apps (also outside the rendering code) there are calls like this:

Code:

if (shape.getAppearance() == null)
{
    Appearance app = new Appearance();
    app.setFoo( bar );
    shape.setAppearance( app );
}

which would behave wrong.

Marvin