Skip to content

Refactor: AbstractShadowFilter reduce object allocations #2516

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

capdevon
Copy link
Contributor

@capdevon capdevon commented Jun 23, 2025

Refactor AbstractShadowFilter: Remove Unused Serialization and Legacy Fields

  • Removed unused imports and legacy serialization methods (write/read), simplifying the class.
  • Cleaned up and clarified Javadoc comments for constructors and author attribution.
  • Replaced legacy temporary variables with final temp fields for matrix and vector operations, improving consistency.
  • Minor improvements in naming and parameter descriptions for clarity and maintainability.

This refactor streamlines the code, reduces clutter, and adheres to modern coding practices without affecting functionality.

/**
* Generic abstract filter that holds common implementations for the different
* shadow filters
*
* @author Rémy Bouquet aka Nehon
* @author Nehon
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why have you changed the author?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The original author's alias 'Nehon' is already the standard signature for most of their contributions, consistent with their GitHub nickname. To maintain uniformity with the other 500 classes in the jme3-core module and to align with this established practice, I've adjusted the signatures in these four Shadow classes. My intention is never to remove an original author's alias from any jME class, only to ensure consistency where a clear alias already exists and is widely used. This change also implicitly supports privacy by standardizing the alias used.

*/
public abstract class AbstractShadowFilter<T extends AbstractShadowRenderer> extends Filter implements Cloneable, JmeCloneable {
public abstract class AbstractShadowFilter<T extends AbstractShadowRenderer> extends Filter implements JmeCloneable {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why remove Cloneable? (Why was it here in the first place?)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The JmeCloneable interface already extends java.lang.Cloneable. Therefore, the explicit extension is redundant and its removal simplifies the code without altering its behavior. Therefore, what checks have you already performed that led you to raise this question?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah yes good point. No objection to removing it then

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants