Apel is a library that brings particle animations to the table with flexible behaviour and a clean developer interface. It promises also lots of predefined shapes & paths to help the developer on their particle scene
Other
2
stars
1
forks
source link
Fix position cache "leak" caused by unique lines #57
The BaseApelRenderer inefficiently cached ApelRenderer.Line instructions by caching every line after rotation and transformation. For animations of reasonably complex models that move and rotate over several hundred steps, this quickly blows out the cache and subsequently the Java heap. This impacts all shapes that use #drawLine, since all of them rotated and translated prior to calling #drawLine.
To fix this, only cache the raw starting lines for any ParticleObject. This has the benefit of pre-computing the intermediate points on the starting lines, which allows for easy, quick rotation and transformation during later rendering steps. This is a 1:N reduction in line point computation, which isn't terribly complex, but is very repetitive.
One "casualty" of this approach is that ParticleQuad no longer provides the modified vertices to its afterDraw interceptor. No other shape did this, so it was a bit anomalous, but since ParticleQuad no longer knows the coordinates of the modified vertices, it cannot provide them to the interceptor.
This also removes ParticleObject#rigidTransformation because ParticleObject (and subclasses) no longer do any transformation; they only describe desired transformations: the renderers perform the mathematics to transform.
The BaseApelRenderer inefficiently cached ApelRenderer.Line instructions by caching every line after rotation and transformation. For animations of reasonably complex models that move and rotate over several hundred steps, this quickly blows out the cache and subsequently the Java heap. This impacts all shapes that use
#drawLine, since all of them rotated and translated prior to calling#drawLine.To fix this, only cache the raw starting lines for any ParticleObject. This has the benefit of pre-computing the intermediate points on the starting lines, which allows for easy, quick rotation and transformation during later rendering steps. This is a 1:N reduction in line point computation, which isn't terribly complex, but is very repetitive.
One "casualty" of this approach is that
ParticleQuadno longer provides the modified vertices to itsafterDrawinterceptor. No other shape did this, so it was a bit anomalous, but sinceParticleQuadno longer knows the coordinates of the modified vertices, it cannot provide them to the interceptor.This also removes
ParticleObject#rigidTransformationbecause ParticleObject (and subclasses) no longer do any transformation; they only describe desired transformations: the renderers perform the mathematics to transform.