在 iOS 版 AIR 中，cacheAsBitmap 对使用滚动矩形遮罩的 Sprite 没有影响
我正在为 iPad 版 AIR 开发一个简单的动态菜单 UI 组件。它基本上是一个符合 iOS 风格的组合框的轻量级填充。我有一个包含 2 到 60 个项目按钮的精灵，可以弹出并让您轻拂/滚动它们，在任何给定时间只显示大约 7 个项目。
我的第一次尝试在我的精灵上使用了一个遮罩，在固定遮罩下上下移动我的菜单精灵。这在测试设备上产生了平淡的结果（< 20 fps）。
然后，我尝试了一种位图传输解决方案，将菜单精灵从显示列表中删除，并使用 BitmapData.draw() 仅将部分渲染到我需要可见的列表中。这在我的 Windows 开发平台上产生了最佳结果，但这次在 iPad 上帧速率降至 10 fps 以下。我假设我遭受了 CPU 使用率过高或 GPU 读回惩罚。最初我希望能够以 60 fps 的速度运行我的应用程序，但我已将目标降低到更简陋的 30 fps。
这让我第三次尝试使用 sprite 的 .scrollRect 遮罩函数和 .cacheAsBitmap 来使用此 UI 组件。同样，Windows 上的 AIR 与 iOS 上的 AIR 之间观察到的行为存在很大差异。在 Windows 上，它仅按照应有的方式重绘由scrollRect 尺寸界定的菜单精灵部分。使用 iOS，我可以触摸菜单精灵可见区域上方或下方的屏幕区域，并且仍然拖动菜单，即使我的手指位于“空白”空间上方！这里的性能还不错，徘徊在 (19 - 25 fps) 之间，如果它像在 Windows 上一样工作，那么在 30 fps 时几乎肯定会是完美的。
有谁对 AIR for iOS 上的scrollRect 功能的行为有任何想法，或者对在 AIR for iOS 中实现 iOS 本机样式滑动菜单的更好方法有任何想法吗？
请注意，上述方法在 CPU 和 GPU 模式下都进行了尝试，但 CPU 模式的表现要好得多。我使用安装在 Flash Pro CS 5.5 之上的 AIR 2.7，并使用 FlashDevelop 作为我的 IDE。
I'm developing a simple kinetic menu UI component for AIR for iPad. It's basically a lightweight fill-in for a combobox that matches the style of iOS. I have a sprite containing any where from 2 to 60 item buttons that pops up and lets you flick/ scroll through them, only showing about 7 items at any given time.
My first attempt at this used a mask over my sprite, moving my menu sprite up and down under the stationary mask. This produced lackluster results on the test device (< 20 fps).
I then tried a blitting solution, leaving the menu sprite off the display list and using BitmapData.draw() to render only the part to the list i needed visible. This produced the best results on my Windows dev platform, but this time the framerate dropped below 10 fps on iPad. I am assuming I was incurring either a taxing CPU usage or a GPU readback penalty. Originally I had hoped to be able to run my app a 60 fps, however I've ratcheted my goal down to a more humble 30 fps.
Which brings me to my 3rd attempt at this UI component using the sprite's .scrollRect masking function in conjunction with .cacheAsBitmap . Again, the observed behaviors differ wildly between AIR on Windows vs. iOS. On Windows it only redraws the part of the menu sprite bounded by the dimensions of the scrollRect as it should. With iOS i can touch the area of the screen above or below the visible area of the menu sprite and still drag the menu even though my finger is over "empty" space! The performance here is decent, hovering between (19 - 25 fps) and would almost certainly be perfect at 30 if it worked as it did on windows.
Does anyone have any ideas either about the scrollRect feature's behavior on AIR for iOS or a better way of implementing an iOS native style gliding menu in AIR for iOS?
Note, the above methods were tried in both CPU and GPU mode, but CPU mode performed vastly better. I used AIR 2.7 installed on top of Flash Pro CS 5.5, with FlashDevelop as my IDE.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
http://esdot.ca /site/2011/fast-rendering-in-air-3-0-ios-android#comment-10
来自上面链接的非常好的人：“是的，scrollRect 基本上在移动设备上是不行的，基本上忘记那个API不管你信不信，老派的掩蔽是我们要走的路！”
http://esdot.ca/site/2011/fast-rendering-in-air-3-0-ios-android#comment-10
Really nice guy from the above link: "Ya, scrollRect is basically a no-go on mobile, basically forget that API even exists. Believe it or not… old school masking is the way to go. Round and round we go!"