Renderer Systems and Pipes for v6.0.0 #7247
bigtimebuddy
started this conversation in
RFC
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
One of the last pieces I want to add to PixiJS before v6 is refactoring plugins. This is a significant API change, though should be backward compatible with existing packages. Would like to get any feedback before I make this change.
Context
Renderer and CanvasRenderer have
plugins
, which are basically a map of classes that get instantiated at runtime and can be statically installed. Thisplugins
object contains things likeextract
,interaction
,accessibility
,prepare
as well as things liketilingSprite
,batch
andparticle
renderers. Renderer also hassystems
, which are mostly an internal concept to represent a pieces of the WebGL stack. For instance, there are systems about filters, render textures, masks, etc.Problem
Having systems AND plugins is confusing. Also, the plugins themselves could be systems if not for historical reasons. Also, the typings are not flexible enough to support property types for plugins or systems. Also, while you can add a system (i.e.
addSystem
) to a renderer, there's no equivalent concept for CanvasRenderer. It's a bit of a hot mess.Solution
The solution is to remove the generic
plugins
as a concept/term, harmonizesystem
usage between renderers, and introduce a new concept call "pipes", short for "pipelines". Pipes are object-specific renderers (e.g., ParticleRenderer, BatchRenderer, TilingSpriteRenderer). Pipes and systems will replaceplugins
.Proposal
plugins
from both Renderer and CanvasRendererRenderer.registerSystem
as a new public APICanvasRenderer.registerSystem
renderer.plugins.prepare
becomesrenderer.prepare
)renderer.plugins.interaction
becomesrenderer.interaction
)renderer.plugins.extract
becomesrenderer.extract
)renderer.plugins.accessibility
becomesrenderer.accessibility
)extends System
and convert to interfaceISystem
, inheritance not necessary for Systems to work, basically each System needs adestroy
function for easy teardown. This is necessary because InteractionManager extends EventEmitter, but also inheritance is not helpful here.registerPipe
andaddPipe
)renderer.plugins.particles
becomesrenderer.pipes.particles
)renderer.plugins.batch
becomesrenderer.pipes.batch
)renderer.plugins.tilingSprite
becomesrenderer.pipes.tilingSprite
)plugins
plugins
map withpipes
mappluginName
withpipeName
on classes like SpriteBeta Was this translation helpful? Give feedback.
All reactions