Is there anything that can be done to optimize existing SWFs for the oncoming wave of retina displays? Or, is there anyway to prepare for retina displays when creating new SWFs? From what I've seen and read, the SWFs look pretty poor.
相关问题
- Core Data lightweight migration crashes after App
- How can I implement password recovery in an iPhone
- State preservation and restoration strategies with
- “Zero out” sensitive String data in Swift
- Get the NSRange for the visible text after scroll
相关文章
- 现在使用swift开发ios应用好还是swift?
- UITableView dragging distance with UIRefreshContro
- TCC __TCCAccessRequest_block_invoke
- Where does a host app handle NSExtensionContext#co
- Swift - hide pickerView after value selected
- How do you detect key up / key down events from a
- didBeginContact:(SKPhysicsContact *)contact not in
- Attempt to present UIAlertController on View Contr
Flex 4.6 supports MultiDPIBitmapSource which would provide a way to supply bitmap optimized for different screen density. You may read an in-depth discussion over this link.
In general, if your bitmaps are used as icon, logo display, where animation or transformation are limited to moving, panning and clipping, and your bitmap it is not scaled, you would achieve optimal display result and descent performance. Vector assets' performance is less predictable compared to bitmap for this usage.
However, bitmaps are not silver bullets to all solutions. They would adversely impact performance as soon as you involve any rotation, distortion or scaling (zoom in and out), this is because the system would have to do a lot more calculation to relocate every pixels, which is a lot more involved compared to vectors.
Stage3D is also worth looking into, but if you are usage is primarily 2D, wisely choose between MultiDPIBitmapSource and vector graphics could be a much simpler solution.
In general, you want to avoid using bitmap graphics as much as possible. If you are using only vector and fonts, these can scale up without issue. The trick to avoid killing the CPU is to use
cacheAsBitmap
whenever feasible, e.g., when the object does not change often. Then you gain the resolution advantage of vector grx, and after the initial rendering gain the speed of bitmap grx.Another tool to start looking into is using the Stage3D. This layer sits behind the Air program, and acts as a robust backdrop. The real advantage is that it uses the GPU, instead of the CPU, which means you have two processors kicking out the grx. If you develop or use coherent foreground and background systems, this can boost your grx performance. One tool that seems nearly ready is Starling 2D. This should help shortcut a lot of the difficult areas for Stage3D. I have yet to use Stage3D, so a lot of this is speculative. I will edit my answer when more experienced.
Edit
@TianzhenLin's response has some pretty good tips. It reminded me that
CacheAsBitmapMatrix
should be used for objects that are going to be rotated, scaled, etc., but not changed structurally.