Pixi.js: Sprite 需要孩子吗？

不，我从未将它用于 PIXI.Sprite。
但我将它用于 PIXI.DisplayObjectContainer（例如：删除所有子项）

需要明确的是，这是关于让Sprite从DisplayObject Sprite继承而不是从DisplayObjectContainer继承，这样它就不能有孩子了。 这将是对Sprite和Graphics的更改，其他任何内容都不会受到影响。

我以前用过这个。 我的用例是一个 Sprite，它使用纹理图集的 2x2 白色不透明部分，这样我就可以在没有任何着色器/缓冲区/纹理开关的情况下渲染矩形和线条，并利用 sprite 批处理器。 它充当了一个小部件的不透明背景，我向精灵添加了孩子。

我很好奇可以进行的优化。 他们在多大程度上属于“过早”类别？

我将从 Twitter 重申我的想法，只是为了让它们记录在这里：

如果说你有一艘太空船并且你想要在它上面闪烁灯光，那将非常有用。 您可能还在船上设置了物理，而不是从船上抽象到DisplayObjectContainer 。

我想我想说的是，我喜欢直接与Sprite交互的心理/模型结构，无论他们是否有孩子Sprite s。

这不是什么大不了的事，但我想如果我有我的理想构造，我不会想要也包含儿童精灵的“特殊情况”精灵。

我不会反对这种改变，但我广泛地滥用了这一点

https://github.com/serprex/openEtG/blob/master/views/Match.js#L241
https://github.com/serprex/openEtG/blob/master/gfx.js#L118
https://github.com/serprex/openEtG/blob/master/views/Shop.js#L89

我有时会使用精灵的孩子。 例如，当我需要创建一个按钮时，要在里面添加文本。 我这样做没有充分的理由，因为我模仿 DOM 的行为，有时发现设置子级相对于其父级的位置更容易。 TBH，当我开始学习 PIXI 时，我不知道如果非交互式精灵覆盖在我的交互式精灵上，是否可以触发事件。 这就是为什么我开始这样做。

我已经使用过这个功能（也在 Graphics 中），但主要是因为懒惰和 hackfestmood。 我赞成仅从 DO 扩展的更改，这会导致一种情况，即我能想到的所有用例都只能以一种很好的方式来完成，不过 @mattdesl案例/问题也很好。

我认为当您想要进行继承旋转时它很有用，例如对于手臂之类的东西，上臂、下臂和手放在一起。 如果您必须使用容器，它将涉及 6 个对象而不是 3 个。

我认为@beeglebug在可用性方面遇到了一些非常重要的事情。

@GoodBoyDigital我们在谈论什么样的性能优化？ 它们会对现实世界产生整体影响吗？ 也许有一个很好的理由有一种优化的Sprite不能有孩子，并且仍然保留现有的Sprite行为。 类似于SpriteBatch vs DisplayObjectContainer

用children为精灵投一票。 ：+1：
对于像我这样的最终用户来说，这是一个明智而简单的 API 模型。
为了这种方便，我很乐意牺牲一点性能。

我的项目目前正在研究使用 Pixi 作为渲染器（更多细节在 https://github.com/phetsims/scenery/issues/350）。 如果 Pixi 节点（包括 Graphics、Sprite 和 Text）不能有子节点，我们实现的复杂性会高得多。 但量化性能权衡也很好。

在这里集思广益：在不使 API 复杂化的情况下尽可能提高性能的一种方法是在添加第一个孩子时让 Pixi 在 DisplayObject 样式和 DisplayObjectContainer 样式之间进行内部切换。 或者这可能只会增加 Pixi 的复杂性以及应用程序启动时间:(

Sprite 需要孩子吗？ 绝对地！！

但是换个角度思考……精灵是显示简单纹理的唯一方法，它们可以有子元素。 为什么没有扩展 DisplayObject 的 Image 类？

这将非常方便，因为大多数人第一次会使用 Image 对象而不是 Sprite。 然后我们可以看看我们是否主要使用 DisplayObjectContainer 并将 Image 推入其中。 或者只是一个 Sprite 和许多其他 Sprite 孩子。

当然他们需要孩子:)
而 Pixi 可能需要一个像位图类这样的附加 DisplayObject（就像 flash API :)）

在我参与的任何项目中，我从未将孩子添加到 Sprite 或 MovieClip。

过去我可能已经向 Sprites 添加了孩子，但我不记得这曾经是主要用例。

如果突然中断，我会切换到充满精灵的文档。

是的，最初我认为这很奇怪，这不是我所期望的，但它很方便，因为上面的许多评论都很方便，尤其是当您想要背景上的图像和顶部的其他元素（例如带有 TextField 的按钮）不太有趣的示例时！ 最初我总是使用 DisplayObjectContainers 来做这件事，但是一旦我意识到 Sprite 可以做到这一点，然后我想当我想要这种类型的功能时我会使用它。

我建议为此创建一个新类，即图像或位图。 这就是 Starling 为 AIR 所做的，否则是的，我想 v3 更新将需要许多项目在这些情况下重构代码。

我正在通过移相器使用 pixi。 我喜欢我可以将精灵附加到其他精灵。

我的意思是，我还能如何建造带有旋转炮塔和动画轨迹的坦克？

（这里的示例：http://jppresents.net/games/tanks/ - 这是通过它使用移相器 2.x 和 pixi）。

示例坦克是一个带有炮塔和小径的精灵作为子精灵。
（有偏移，如果炮塔有自己的旋转）。

一切都与主精灵（坦克体）一起变换（移动、旋转），无需任何额外代码。
如果没有孩子，这将如何运作？

来自 Starling 和 Adob​​e Air 背景，我最初认为“有孩子的精灵？ 哎呀！
但有时我发现我需要另一个额外的 sprite，我最初只放了一个 sprite，最终出于纯粹的懒惰使用了该功能，而不是费力地将第一个 sprite 交换为 DisplayObjectContainer 等等。 所以这是我能看到的唯一好处——为懒惰的人提供一个懒惰的选择。 不过，我确信以某种方式扩展 DisplayObject 会更简洁。 我看不到任何场景，在其中拥有 Sprite 的孩子可以实现任何仅通过使用 DisplayObjectContainers 也无法或多或少地同样实现的好处，即使它确实意味着总体上有一个或两个以上的显示对象。

就其价值而言，我也从未在任何 Pixi/Phaser 项目中使用过 Sprite 的孩子。 不过，我过去经常在 Flash 中做这件事，感觉更自然。

话虽如此，我知道很多开发者确实在他们的游戏中使用了这个功能。 我的一部分认为，如果您要声称您支持真正的显示列表，那么您实际上需要支持真正的显示列表！ 然而，DOC 可以做 Sprite 孩子可以做的一切，只是在设置它们时更加冗长——它们需要更多的对象，因此需要更多的内存，以实现您目前可以做的完全相同的事情。

如果这只是为了加快批处理速度，那么也许非容器基础对象更有意义？ 就像 Particle 或 Image 类。

人家说了算！ :)
带孩子的精灵吧！

谢谢大家的反馈！

我想补充一点：

如果无子 DOC 具有优化潜力，那么动态检测无子 DOC 可能是可行的方法。 如果可行，为什么同时拥有 DisplayObject 和 DisplayObjectContainer？ 为什么不是所有的 DisplayObjects 都能够包含孩子？

+1 我也对这个很好奇。

我在这里看不到任何性能的好坏。 对我来说，这似乎是一个组织问题。

如果精灵可以有子元素，您可以更轻松地扩展代码。

但是，是的，无子精灵列表需要易于访问。

那么，DisplayObjectContainers 的意义何在？ 只需将所有东西都变成一个精灵，它可能有也可能没有孩子，或者可能有也可能没有附加纹理。 （是不是太复古了）？

我的 Phaser 术语可能比较模糊，但对我来说，我从不使用 Sprite。 基本上，如果我需要一个 DisplayObjectContainer，我会使用一个组。 如果它是一个 DisplayObject，我使用一个图像。 我事先知道我正在构建的内容的关系，并且看不出为什么我会创建一个同时执行这两个操作的节点（除了混乱）。 我发现只管理一个显示对象容器来构建我认为是“Sprite”的东西更容易。

在 PIXI 中，精灵只是一个带纹理的对象。 Phaser.Group继承自PIXI.DisplayObjectContainer 。 Phaser.Image继承自PIXI.Sprite （继承自PIXI.DisplayObjectContainer ）并显示纹理。 Phaser.Sprite也继承自PIXI.Sprite并显示纹理并包括物理和动画。

我意识到这是一个_真的_老问题 - 但我正在尝试将 PIXI 抽象为反应渲染器，并且那里的性能影响很大。 不是在 PIXI 方面，而是在 React 方面。

我现在的计划是有两种类型的 Sprite 包装器 - 那些可以有孩子的和那些不能有孩子的，默认的Sprite是那些_不能_的。

这是已经有命名约定或在 v5 中拆分的东西吗？ 我的意图是将容器化版本命名为“SpriteContainer”。

同样，这并没有涉及任何 PIXI 内部结构，并且在这两种情况下它仍然是 Sprite - 只是想确保我没有遗漏一些预先存在的命名约定；）

很难解释 DisplayObject 和 Container 的区别，它们有点相同，只是功能分离，它来自 Flash。

在 flash 中，Sprite 也可以有子节点，它基于 DisplayObjectContainer

你的实验进展如何？

到目前为止，实验进展顺利...... React 绝对是一个瓶颈，但在大多数情况下并不是一个瓶颈。

如果我能让这个改变起作用（边缘不能是容器），那么 react+pixi 的性能大约是 20,000 个兔子，而 pixi native 的性能大约是 50,000 个兔子。 完全可以用！ 但我需要先介绍一下这个变化......

只是想知道这里的用例是什么？ 可以给你的链接吗
工作？

2017 年 10 月 4 日上午 12:32，“David Komer”通知@ github.com 写道：

到目前为止，实验进展顺利...... React 绝对是一个瓶颈，但
在大多数情况下，不是一个表演者。

如果我能让这个改变起作用（边缘不能是容器），那么
react+pixi 在大约 20,000 只兔子中表现，而 pixi native 在 20,000 只兔子中表现
大约 50,000 只兔子。 完全可以用！ 但我需要介绍这个变化
第一的...

—
您收到此消息是因为您发表了评论。
直接回复本邮件，在GitHub上查看
https://github.com/pixijs/pixi.js/issues/1380#issuecomment-334047182或静音
线程
https://github.com/notifications/unsubscribe-auth/ADFJWGJkslw1Nz1okGAM1BXMOm89XYVhks5sowpMgaJpZM4DW7sQ
.

@agamemnus - 用例是用 React 驱动

我刚刚完成了一些初步的基准测试……编写自定义渲染器对性能没有帮助。

但它确实有助于可用性:)

刚刚在 PIXI 论坛上提交了带有代码和演示链接的主题： http :

此线程已被自动锁定，因为它在关闭后没有任何近期活动。 请为相关错误打开一个新问题。