有没有人经历过使用 getObjectsUnderPoint 的副作用（包括性能问题）？
在我对正在进行的游戏项目进行重大更改之前，我只想听听其他人是否发现 DisplayObject 的 getObjectsUnderPoint() 函数有任何问题？
更新： 不仅仅是性能问题，还有使用它的任何其他限制（比如它没有检测到某些类型的 UI 元素（仅作为示例））
我的应用程序中将有三层（这是一个等距游戏）
- 背景 - 这只是一个留在底部的背景，与游戏无关
- 中间层 - 这是可玩区域，这里我所有的游戏元素都将放置在这一层
- 顶层 - 这是一个虚拟透明层，覆盖整个可玩区域，会中断所有鼠标事件。这是我想使用 getObjectsUnderPoint() 的地方，
因此，玩家想要单击该元素，顶层将中断 mouseevent，然后检查是否放置了某些东西或只是一个普通的背景，并采取适当的操作，例如通知下面的元素目的。
这确实不需要这样做，因为我可以简单地为直接放置在地图上的所有项目添加 moues 事件，但因为无论如何我都会使用 getObjectsUnderPoint() 来检查项目下方是否有任何东西。
如果有人能解释这个功能是如何工作的，那么我就很难做出决定了。
Before I go making major change in my ongoing game project, I just want to hear from others if anyone has found any issues with getObjectsUnderPoint() function of the DisplayObject?
Update:
Not just the performance issue but any other limitations of using it (like it doesn't detect certain type of UIelements (just as example))
I will have three layers in my application (which an Isometric game)
- Background -- This is just a background which stays in the bottom, has nothing to do with game
- Middle Layer -- This is the playable area, Here all my game elements will be placed on this layer
- Top Layer -- This is one dummy transparent layer covers entire playable area which interrupts all the mouse events. This is where I want to use the getObjectsUnderPoint()
So, player wants to click on the element, the top layer will interrupt the mouseevent and then check if there is something placed or just a plain background and take appropriate action like, notify the underneath object.
This really doesn't require to be done this way because I could simply add moues events for all those items placed on the map directly but because I would be using getObjectsUnderPoint() anyway to check if there is anything beneath the item.
If anyone can explain how this function works then it would be little easy for me to make a decision.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
但有一个恼人的问题。我不知道他们是否修复了它。至少在10.1倍的时候就有了。
如果您有一个容器并对其进行了缩放，
container.getObjectsUnderPoint将返回错误的结果。一直以来。因此，在任何需要getObjectsUnderPoint的地方，我都必须从stage调用它才能获得正确的结果。There was one annoying problem though. I don't know if they fixed it or not. At least it was there in 10.1 times.
If you have a container and you scaled it
container.getObjectsUnderPointwill return wrong result. All the time. So everywhere where I neededgetObjectsUnderPointI had to call it fromstageto get proper result.这是一个不完整的功能。它返回鼠标下的图形对象，而不是用于事件或交互目的的所有潜在鼠标目标。它实际上需要复杂的逻辑来检查 getObjectsUnderPoint 返回的数组以确定鼠标目标，因为适当的目标（如果您实际单击该点，Flash 将选择的目标）可能不在列表中。
首先，您必须反向检查对象数组，因为项目是从后到前排序的。您必须检查每个对象的整个父级链，寻找 mouseChildren = false 的父级，这将导致它拦截事件并成为目标。无论是否找到这样的对象，您到达的最终对象都必须将其 mouseEnabled 属性设置为 true，否则您必须跳过它并移至数组中的下一个对象，例如，下一个精灵或形状位于您最初检查的形状后面。在浏览列表时，您必须注意父级何时更改，此时您需要假设该公共父级的所有子级都将其 mouseEnabled 属性设置为 false，在这种情况下，父级将成为下一个候选者。这实际上非常复杂，因为您正在以自下而上的方法向后工作，并使用自上而下生成的一组不完整的对象。
为了获得实际的潜在鼠标事件目标，与默认的调度逻辑一致......实际上更容易以自上而下的方式从舞台开始，并以深度优先搜索的方式向后遍历显示层次结构，检查 mouseChildren 以确定是否需要单步进入子级，并检查 mouseEnabled 是否要成为目标，否则单步进入容器的子级并再次从后到前重复该过程。这是更加准确、完整和直接的。唯一的问题是你必须自己编码。
It's an incomplete function. It returns graphical objects under the mouse, NOT all potential mouse targets for event or interaction purposes. It actually requires complex logic to examine the array returned by getObjectsUnderPoint to determine the mouse target, because the appropriate target (the one Flash would choose if you actually clicked that point) may not be in the list.
First you'd have to examine the object array in reverse, since the items are ordered back to front. You'd have to examine each object's entire parent chain, looking for a parent with mouseChildren = false that would cause it to intercept the event and become the target. Whether or not such an object is found, this final object you arrive at must have its mouseEnabled property set to true, otherwise you must skip it and move on to the next object in the array, which would be, for example, the next sprite or shape behind the one you initially checked. While going through the list, you must notice when the parent changes, at which point you need to assume that all children of that common parent had their mouseEnabled property set to false, in which case the parent would become the next candidate. This is actually extremely complicated, because you're working backwards in a bottom-up approach with an incomplete set of objects that was generated from the top-down.
To get actual potential mouse event targets, consistent with the default dispatching logic... it is actually easier to start from the stage in a top-down manner and walk backwards through the display hierarchy in a depth-first search, checking mouseChildren to determine whether you need to step into children, and checking mouseEnabled if it's to be a target, otherwise stepping into the container's children and repeating the process from back to front again. This is much more accurate, complete, and staightforward. The only problem is you have to code it yourself.