Pixi v3.0.0 #1296
Comments
|
NIIIICE 👍 |
|
This may be a bit off topic, but on the matter of a complete rewrite & removing unnecessary bits: why does Stage exist? It's consistently suggested to only use 1 stage, & juggle DOCs. Why not have renderers take DOCs directly & skip the existence of Stage? The only thing Stage seems to really offer from DOC is that it handles interactionManager, but if interactionManager is being made more modular, it might make sense to pass a renderer or DOC to an interactionManager rather than a stage |
|
@serprex Good point, I think I really agree with that and will add a phase for investigating and implementing it. |
|
Wow! This is a hugely ambitious task. Here's some of my thoughts. Hopefully it doesn't come off too critical -- Pixi is already an awesome project! In an ideal world everything would be modular, but I don't think it's realistic for Pixi to end up as modular as projects like npm-dom and stackgl. The nature of that kind of modularization would turn Pixi 3.0 into another project altogether, unrecognizable from its earlier versions. However, there is a lot of code in Pixi that could potentially be split into its own framework-agnostic set of modules. Pixi also does a lot of things that are already possible with the npm ecosystem. These changes would greatly improve the readability and maintainability of Pixi, and it would overall make contributions and bug-fixing easier and more pleasant. There would be fewer situations where changing a small piece of code in one file breaks a dozen other unrelated files. agnostic modulesJust a warning... It can be very tempting to try and modularize a framework by publishing its separate domain-specific objects and features as their own modules (pixi-text, pixi-point, pixi-texture, pixi-filter, etc). This can easily end up in a sort of module spaghetti. I think the best approach is to take baby steps, publishing the agnostic bits of code that have no ties to a larger framework. The published modules should not have side effects (global state), they should avoid mutating user objects (i.e. can't use philosophiesPixi is a really awesome framework, but it's also really difficult to contribute to, and very prone to bugs. Part of the reason, I think, is because of the code style. Almost every method has side effects, there is an incredible amount of obscure inter-dependence across modules (like I think a re-write would be all for naught if some of these problems are not addressed very early on. scopeA lot of things in Pixi are out of the scope of a rendering framework (and maybe even out of scope of a game engine). Things like modularizationIn terms of modules that Pixi could already start taking advantage of, there are dozens:
And there is of course the stackgl packages, some of which could be a great groundwork for the WebGL bits (which are currently sprawling and tangled through Pixi). |
|
Great post @mattdesl, I have updated a few sections with inspirations from this. I agree with most (all?) of what you are saying so let me try to address some of it:
After I replace code in pixi with external existing modules, what code is left that is pixi-specific that could become agnostic?
The "Decoupling and API Normalization" phase of this rewrite is aimed to fix a lot of these issues, its goal is to make the "separate modules" created in the previous phase actually be separate modules. That includes removing the leaky abstractions, interdependence, and global dependence.
Exactly, this is why I want there to be
This is a great point, and something I planned to do but I noticed I didn't write it up in this doc. I have updated a phase to be "Prefer dependencies and create custom builds" that will include refactoring out this type of common code. As I do phases 1-3 they are mostly serial due to the nature of moving around files and touching almost everything. But, once I reach phases 4-8 those can be done in parallel and I am hoping some people from the community can step up and help me complete some of those phases. If not, I will be doing my best to try and get as much done as I can before the new year. |
|
Why not use https://github.com/pixijs? Will it be used in the future? |
|
@lain-dono I created that org, if I can convince @GoodBoyDigital I'd love to move main development to there. |
|
Howabout a Typescript definition file ? right now thats a separate project, |
|
@whizzkid That isn't really in scope for what I am trying to do here. This is about getting pixi to run like a well oiled machine, and make it easier to write and maintain. Unless we can generate a typescript definition at build time, I think it is out of scope for us to maintain one by hand in this repo. |
|
@englercj First off a big 👍 for this writeup, the work that has been done, and what is yet to do! Secondly, another 👍 to @mattdesl post as well, lots of great info and resources. Lastly my 2¢:
These items (plus renderer of course, and interactions) can easily represent the first line of modular separation. The canvas is probably the most simple in that it would be nice to circumvent the need for a canvas in general, and just provide the context directly. IMO I would like both the retrieval of a canvas, and a context to be delegated with default providers of each. Asset management makes sense to be in a centralized location for the purposes of optimization and a unified api, but this does not necessarily mean a hard dependency on any network implementation. Think of something like an Asset manager/router with with middleware able to register loaders, caching, and other handlers. A loader can be as simple as an XHR, a FileReader, Blob, etc.. Back to the InteractionManager, or in general user Input... This should also be completely decoupled from from the DOM. I would love to be able to project input into Pixi regardless of what type of DOM event it may be derived from. These projected points can then be propagated through the Pixi render tree with a normalized interface, a very rudimentary example: var interaction = interactiveObject.interaction(x, y); // mousedown, touchstart, pointerdown, input from gamepad that just connected
interaction.move(x, y); // mousemove, touchmove, pointermove, updated gamepad status
interaction.end(); // mouseup, touchend, touchcancel, pointerup, click, gamepad axis normalized
interaction.dispose(); // cancel triggered if end not invoked beforehand. mouseout, touchcancel, gamepad disconnected etc..This is again very rudimentary, but the idea is that Pixi does not really need to care about what type of input triggered an interaction, it just needs to know where to hitTest, how to propagate (light weight) synthetic events through the render tree, and when to do it. This process can be limited to only interactive objects in the scene, and the developer has the choice of which interactive object in the scene the event will bubble to. The source of the interaction itself makes sense, something like Update: Text also has some pretty tight coupling with the DOM, but I'm not sure what the best answer is there at the moment. |
|
Hey all! Finally got a bit of internets on my travels and really good to see whats been cooking up here! Nice work @englercj! Totally up for modularizing the code for v3 and really like what you have done so far @englercj! Will using browsefy modules still build a PIXI object that can be used the same way people currently use pixi? "This phase will also take this opportunity to try and refactor out custom code in favor of more mature modules in the npm ecosystem." My brain is a little concerned about phase 4 as integrating other modules as it seems like it could add layers to pixi that may not be required. But thats something we can talk about when we ya get to phase 4 :) Should be back on the 15th Jan and super keen to put some thinking time into the whole proposition! Great effort so far though @englercj 👍 |
Nothing changes for users that use pixi in the way they use it now, the final built file works the same way. All it does it let other browserify users and node users have easier access, and we get access to npm modules, and the code is much cleaner.
Not sure what you mean, this doesn't add code, it removes it. It is removing layers from pixi so that there is less code to maintain and create custom. Instead we use mature modules that are well tested and therefore reduce our complexity and bugs significantly. I think that this is one of the most important parts of this, because pixi has a lot of bugs because we reinvent the wheel so much. |
|
Nice nice! I disagree with your last comment though - reinventing the wheel (to a certain degree) is what made pixi what it is and how we manage to get such good performance so far. It also lets us try new ways of doing things which is very important to me. I know this is down to personal taste, but I'm not really a fan of the tiny little modules that pop up on npm. I want to make sure that pixi does not become a collection of fragmented code that requires a bunch of tiny little modules that more often than not could simply be a function. That said I will certainly keep an open mind about what your are saying and as we come to that part we can discuss it. I agree that structurally its evolved and is in need of a tidy. Pixi is very important to me (as it is to you) and I just want to be VERY careful with these big proposed changes. Cheers! |
|
@englercj I kind of disagree with that last comment too, for a different reason. I do not think reinventing the wheel is the reason there are bugs, but it does contribute to them popping up. |
|
I think before any of this is even started you should all try and answer a fundamental, yet basic question first: What do you actually want Pixi to be? Although billed as a 'renderer' I think everyone here can agree it never really was just that, even from the start. It has clearly evolved as a result of how @GoodBoyDigital needed to use it on a day-to-day basis internally in their client work. This is obvious from the way features were added. It grew based on what could be deemed a 'client led' roadmap. This isn't a bad thing necessarily, but as the popularity of Pixi grew it bought into question why some of those choices were made. With a project like this I think it's fair to say that its structure is a direct result of the workflow that goes on within the GoodboyDigital team, who are arguably the most important Pixi user of all. If browserify was a core tool they used internally then I have no doubt you'd see Pixi using it already, but it clearly isn't. The moment they start questioning if it should be used is the moment the project will loose momentum and start mothballing. Pixi development isn't a purely altruistic endeavour. It has to either remain a vital core part of Goodboys day to day workflow, or be so open and well adopted that the wider community can and will carry out all development instead. I believe this is a fine line. Assuming a rewrite in this manner will suddenly open the flood-gates to developers who wouldn't otherwise have helped is wishful thinking at best. I believe the reality is that there's a very finite number of developers who have the technical ability to help anyway. If Mat were to spend time writing in detail how Pixi works, explaining about the batch process, the shaders and the rest of the internals then I can't help but think this single act could help bring in more developers in than any other actually. But that's an aside (and really could do with happening regardless) If Pixi is to truly be a pure renderer and nothing else then it needs entirely stripping out and turning into such. From this then perhaps @GoodBoyDigital could work Pixi into a new project that adds in all of the extras they actually need for day-to-day work and not even have them as part of the core library (even in module form). However as Pixi isn't really a renderer at all right now (it's turned into a bit of a swiss army knife!) then maybe this is where the discussion should start off? I think both Mat and Chad (and everyone else!) should agree with a joint definition, which should evolve into a core features list and roadmap, before any code is touched at all. |
It's hard to say, since so much of Pixi is written with side-effects and thus generally harder to "rip out" into decoupled modules. For example, the ellipse function (using quadratic curves) would be useful in a module, but not in the current way it's written.
Do you mean like passing a CanvasRenderingContext2D to the WebGLRenderer? I would be in favour of this, and I've started doing this in my own tools. When something needs to operate on a webgl/2d canvas, I prefer passing around contexts for a few reasons:
On the topic of re-factor, I really think that ThreeJS-style object options in constructors might be worth considering. Especially for WebGLRenderer, which has become annoying with the mix of required/optional parameters.
Small and focused modules will help minimize this problem. If a module is "too big" or doesn't do something quite in line with how Pixi should do it, then it might be a case where a new module can be created. The benefits:
@photonstorm I agree with your points. Ultimately everything is up to the GoodBoyDigital team since they will be the ones that continue to maintain and improve Pixi. If they don't like the browserify / small modules route then a rewrite of this magnitude would have negative effects on the future of Pixi, and a fork (new project name etc) might be a better approach. I have stopped using Pixi for personal projects because it does not produce re-usable code, and because it's usually overkill for the work I do. Every day Pixi seems to grow exponentially (in size and complexity), with new features that 99% of the time I will never need. I still use Pixi at work because it's well documented (good for teams / juniors) and because the existing ecosystem of npm modules have not caught up to it. This will probably change in time, as stackgl and similar projects become more mature. |
Yes. Update: More precicesly, a
👍 |
|
Hello all! @mattdesl thanks for sharing so much information! That combined with a decent conversation with @englercj has really helped in my understanding of this approach. The penny is starting to drop as it were and I'm starting to get more excited! I still need to see and engage in this new philosophy for me to truly get to grips with it I feel, so im certainly up for giving it a go and seeing where this heads. Just be prepared for some silly questions :) Research and playing around for me when I get home i think... With regards to the things I do understand a lot better.. I'm 100% on board with a solid refactor of certain core parts of pixi that will make it much easier for people to only use the parts of pixi that they need to use rather than rolling it all into one big ball that includes everything. A more DRY approach and following this lovely statement: "Make modules be standalone, defined as: they don't require extra code for their use-case to be added to core." After driving a car for 10 hours today I had a lot of thinking time and have a few solid ideas that I am confident will get us to that goal! I guess my question to you all is what would you consider to be core pixi? would it be as simple as: webGLRenderer That seems like it would be pretty nice and bare bones to you all? And a few more thoughts.. -Whats pixi all about? The two most important things to me for pixi are this: How we ended up where we are.. The focus on pixi so far has always been on the end result and it performing what is required. The requirements have come from either a necessity for a project I'm working on or community feedback from its users. So its has kind of grown fairly organically. This has been a good thing in terms of finding out what pixi is actually useful for! I am confident that what we have feature wise is strong and to be honest I don't think that there are any left that need to be added to pixi as it is. Certainly some refactoring, making existing features stronger and moving some out of the core offering.. But not any real new ones! I do have some higher level ideas but they will certainly be plugins and separate (A 2D dynamic lighting system "pixiLights" being one of them!) So yup, I honestly think they are the 2 main reasons that the uptake has been so good this year! So with that in mind I think the idea of making pixi leaner and generally more module is a thing that has to happen. That way more advanced users can pick and choose the elements from pixi that are required for their projects and new comers or people who don't wish to dabble can have the same experience they currently have when using pixi. win win right? Also @mattdesl out of curiosity, what are your thoughts on existing engines like three.js? |
LightSpriteBatch and stuff from http://www.goodboydigital.com/pixijs/pixilights/? It is not perfect-pixel shadows. Right? |
|
The thing to keep in mind is that the re-write is only a small step toward modularity. Pixi is never going to end up as modular as, say, stackgl. And that's OK, since most people are happy with Pixi as-is. At a high level the goal of npm modules would be to: "use dependencies to make the codebase more manageable." Examples:
I'm sure the options will become more clear as more work is done on the rewrite/fork. |
|
If you're planning a massive rewrite, why not future-proof with ES6 modules using SystemJS? |
|
@kittykatattack We had that discussion a million times now, the basic gist is:
and many other reasons you can find by searching around the issue list. |
|
@englercj Thanks for explaining that |
|
ES6 is pretty fantastic in some ways; 6to5 produces very clean transpiling for things like arrow function, spread, default params, rest, string templating, classes, etc. It plays fine with modules and npm. :) But it's a different beast, introducing some new complexities for contributors, and brings to question what happens when some es6 code is pulled out of core into its own module. @gre I've been on both sides of the fence with signals. On large projects signals have some advantages, but more recently I've found events play better with npm/modules as a whole, and also have potential for FRP down the road. The real selling point of events for me is code readability: var foo = createFoo()
//is this a signal? a boolean? a jQuery-like getter function?
console.log( foo.started )
foo.started.addOnce(handler)Compared to events which does not carry the same ambiguity, and reads almost like regular English. "Once foo is started, do handler." var foo = createFoo()
foo.once('started', handler)But I admit it mostly comes down to personal preference, since the differences are pretty minor. :) |
You still have to use CJS for npm modules, you can't just do raw ES6 and the node ecosystem suddenly works. Unless I grossly misunderstand something you are talking about compiling the ES6 then publishing that? |
|
Yeah, but in the case of Pixi v3 we already have a bundle step (browserify) so adding 6to5ify would be pretty transparent to end-users consuming with npm / bower / whatever. It gets a little more complicated when you have separate modules, because those might not need a bundle step (i.e. point-in-polygon is just raw source). With that said, I don't really think ES6 is necessary for Pixi. EDIT: Although, if npm users are expected to require the raw source of Pixi it would be really complex. Because then you'd have a separate "browserified bundle" (with deps) and "transpiled bundle" (no deps) ... nasty. I guess that's what you're talking about |
|
@mattdesl I meant us using npm modules. Even when using browserify we have to include npm modules with |
|
You can require stuff and still take advantage of es6 features. :) |
|
@mattdesl Of course, I just don't think there are many worth us implementing for our use cases. |
|
just bumping this one to say how impressed I am at the rate and work you two @englercj @GoodBoyDigital are pumping out in the dev branch. |
This comment was marked as spam.
This comment was marked as spam.
|
Some wonderful brilliance going down here, thanks for being so awesome guys! @GoodBoyDigital @englercj |
|
Just had a quick perusal of progress, also very impressed! Hope it's ok to add 2 (more) ¢, probrably not the last ;) I notice there are a couple, or few mixins now in existence, e.g. cacheAsBitmap, interactionTarget, eventTarget. I have no issues with this pattern, many times it is perferred, but having quite a bit of experience with react.js, I do like having things organized in such a way that a mixin is easy to spot, either by directory structure, module name, or both. Just a thought. |
|
Will version 3 have a download similar to the way it is now? |
|
I'm not the owner here but I guess that's for sure. and if not, it is very easy to make one. Keep up the great work guys |
|
@SharpleafCC You will never have to build pixi.js yourself if you don't want to. We will definitely have a distributable that browserify will build for us. |
|
Closing this now since we have completed the scope of this issue. |
|
Does this mean v3 is ready? :D On Sun, Mar 8, 2015 at 6:37 PM, Chad Engler notifications@github.com
|
|
👍 great work! |
|
@SharpleafCC No, it means the scope laid out in this issue has completed. The developer preview is out if you want to start working with the new lib, and we should be able to release the official v3 soon. |
|
Does "developer preview" mean "whatever is currently in the |
|
@lucasb-eyer Developer Preview means "pre-release for developers". The |
|
I didn't even know about the github releases page! Thanks for the link and sorry for the noise. |
|
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Current Status
Total Rewrite Progress: 100% complete
Reminders for myself:
Proposal
Introduction
Hello all, I decided to write this up to inform the community what I am working on and to gather some feedback. The biggest thing to realize about what follows is that I am working on it right now, and that it is no longer theoretical. Also, keep in mind this has not yet be "blessed" by the rest of the Pixi team so this may not make it in, I am just looking for feedback from the team and the community.
You can watch the work being done in a branch on my fork: https://github.com/englercj/pixi.js/tree/dev-rewrite
If you read this proposal and want to help, fork my branch and submit PRs to the
dev-rewritebranch and lets get this done!That being said, v3.0.0 will be a rewrite of PIXI. I have it split into distinct phases with clear goals to accomplish a clean, modular library that will make it easier for us to maintain and for others to contribute.
Rewrite Phases
Phase 0 - Cleanup/Meta
Status: Completed
Phase 0 is to cleanup the code repository, removing things that shouldn't be in the main repo. For example:
examples/,docs/,trim/. Each of those should be separate and maintained on their own. It also converts the project to use gulp, reorganizes the tasks for the project, and generally prepare the project for the coming rewrite.Phase 1 - Code Modularization
Status: Completed
Related issues: #307
Phase one is to convert the codebase to use browserify, remove dead code, convert yuidoc to jsdoc comments, and cleanup some style inconsistencies. This is perhaps the most time consuming phase because it requires combing through every source file in pixi and changing a lot. This phase will make it much easier to refactor the library and accomplish later phases.
Phase 2 - Component Modularization
Status: Completed
Once the library has been revamped from a code-quality standpoint the next step is to remove circular dependencies and split the core library into multiple discrete modules. Each module will be in a separate folder within the
src/directory of the project, but should be split into separate repos at a later date.The modules I have in mind are:
core- Core renedering and display (math, DO, DOC, Sprite, SpriteBatch, Graphics, textures, renderers).spine- Adds spine support.loader- Adds loaders for the different things pixi supports.filters- Adds a pack of different filters.text- Adds text support.extras- Adds TilingSprite, and MovieClip support (could use a better name).interaction- Adds user interaction support.Phase 3 - Decoupling and API Normalization
Status: Completed
At this point the project has been split into multiple "modules" within the repo, but are still interdependent on each other. That is, even though the code is separated you couldn't have a custom build that leaves out pieces because they are too tightly coupled. This phase is to decouple modules from each other and let them be standalone. Core should work fine on its own, and other modules should just extend core and add support. There are also leaky functions and a lot of dependence on global state, that should also be removed in this stage.
This phase also includes modifying strange inconsistencies in the API to unify it a bit. For example, sprites have properties for filters/masks but to set the texture you use a method. Fixing some of these evolution in the code will result in easier integration and maintenance.
Phase 4 - Prefer dependencies and create custom builds
Status: Complete
Related issues: #1283
Now that modules exist, and are decoupled, we can create custom builds that include only subsets of the pixi functionality that users can tailor to their needs. This phase will also take this opportunity to try and refactor out custom code in favor of more mature modules in the npm ecosystem.
Some modules we can start using (thanks @mattdesl):
geompackagePhase 5 - Rewrite Interaction Manager
Status: Completed
Related issues: #241, #325, #346, #785, #950, #1096, #1252, #1291
There are a lot of issues related to the interaction manager and how it works, this phase will be a rewrite of this module so clear up some of the issues people have been reporting. Hopefully when this is done we will have a clearer interaction manager along with DOM-like bubbling, and real events (instead of raw callbacks).
Phase 6 - Rewrite Asset Loader
Status: Completed
Related issues: #312, #387, #776, #1290
The loader has evolved a lot over time, and some of the older components got left behind. The API for it is a little hap-hazard and awkward. This rewrite should address the issues the community has with this module, increase performance, and make it easier to maintain.
There is also still a coupling of the core code to the texture caches used by the loaders. This phase should remove that.
Phase 7 - Rewrite Stage
Status: Completed
Related issues: #1232, #1264, #1285
There is a lot of confusion over what
Stageis and why it exists. Many people have asked "why can't I pass any DOC and have it rendered?" This phase will be to implement that functionality and remove the stage from the library.Phase 8 - Optimization/Cleanup Pass
Status: Complete
Related issues: #1097, #1238, #1260
There are a couple hot functions that could use an optimization pass. Lots of temporary variables and other things that cause GC churn that need to be fixed. This phase is to clean up those parts and help make pixi as clear and effective as possible.
I also want to cleanup some long standing issues in this phase, that should be pretty simple to solve. Most involve some "messy" code that should be simple to clean up. I will also take this opportunity and go through all the
TODOcomments in the code, and actually do them.Phase 9 - Rewrite Examples
Status: Complete
The examples have a ton of code duplication, and no framework for actually creating them making it tedious if not difficult to add more examples. In the new examples repo there should be a framework for easily creating new examples using a handlebars/assemble/gulp build process. Code can then be shared via browserify.
Completion
After these phases I feel that pixi will be in a good state to be extensible and maintainable by the community. If you have feedback, or questions I'd be happy to try and answer them here. This effort should go towards fixing 20+ issues in the list and make it much easier for other developers to jump into the code and fix issues on their own in the future.
The text was updated successfully, but these errors were encountered: