在位图上绘图与直接在画布上绘图
在我的应用程序中，我需要绘制一个大型网络（基本上是用线条连接的小盒子），用户将能够缩放和平移它。
我的第一个选择是将网络直接绘制到画布上，但我认为这不是很有效，因为每次发生平移事件时，绘制过程都会重新开始。
因此，我尝试使用一个大的可变位图，只绘制一次整个网络（或者至少在缩放发生时），并将必要的区域传输到画布上。
我的问题是，由于网络相当大，我在创建位图时遇到 OOM 异常......
我该怎么办？直接在画布上画图？使用几个较小的位图？
谢谢， 迪雷兹
In my application I need to draw a large network (basically, little boxes connected with lines) and the user will be able to zoom and pan it around.
My first option was to draw the network directly to the canvas, but I thought that was not very efficient, because each time a pan event occurs, the drawing process begins again.
So I tried to use a large mutable bitmap and draw my entire network only once (or at least whenever zoom occurs), and blit the necessary areas to the canvas.
My problem is, since the network is rather big, I get OOM exception when creating the bitmap…
What should I do? Draw directly to the canvas? Use several smaller bitmaps?
Thanks,
Direz
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我问你的第一个问题是你同时有多少个精灵？到目前为止，由于硬件加速，在屏幕上显示多个精灵的最快机制是使用 OpenGL。最重要的是，在 Android 上，我发现这样做是使用 Google Projects 上提供的 Cocos2d android（不要与 ios 版本混淆）。不过，您必须使用 IOS 文档才能理解它，并且有一些不错的在线教程可以开始使用。特别是这里的 hello world 模板... Www.sketcHydride.com/Blog/p?= 8.与最新的 IOS cocos2d 相比，它已经过时了，但这是可以预料的。在我的实验中，我发现当未连接到活动调试器会话时，程序运行速度要快得多。
如果您想坚持使用当前的方法，或者上面的方法仍然不够快，您将不得不尝试剔除任何未出现在屏幕上的绘图，这意味着形式的一般函数“如果精灵的 x 和 y值超出了可见区域的范围，请勿绘制它”，这基本上是大多数图块基础游戏处理该问题的方式。
如果你画的是小方块，听起来你是在手动绘图。我认为更建议继续在画布上绘制，但要非常小心地管理精灵计数并避免出现大量的 for 循环迭代
帧更新尽可能循环。通过绘图操作来充分利用你的小手机是相当容易的。
另一种选择可能是将整个位图绘制到内存中，然后使用复制矩形操作将图像传输到屏幕，而不绘制您创建的完整位图。我认为复制矩形通常应该是一个快速的操作，但如果你用它来绘制整个屏幕，它看起来有点矫枉过正，可能也不起作用。
My first question to you is how many sprites you have going at once? By far, the fastest mechanism for having many sprites on the screen is to use OpenGL due to the hardware accelleration. The besy way, on Android, I have found to do this is to use the Cocos2d android (not to be confused with the ios version) which is available on Google Projects. You will have to use the IOS documentation in order to understand it though and there are a few decent tutorials to get started with online..in particular, the hello world template here... Www.sketchydroide.com/Blog/p?=8. It is out of date compared to the latest IOS cocos2d but thats to be expected. I have found that the programs run MUCH faster when not connected to an active debugger session in my experiments.
If you want to stick with your current approach or the above is still not fast enough, you are going to have to attempt to cull any drawing which does not appear n the screen meaning a general function of the form "if the sprite's x and y values are outside the bounds of the visible area, dont draw it" which is basically how most tile base games handle the issue.
It sounds like you are doing the drawing manually if you are doing little squares. I think it is more adviseable to go ahead and draw on the canvas but to be very careful about managing your sprite counts and to avoid heavy for loop iteratiins that occur on
the frame update loops where possible. It is rather easy to max out your little handset with drawing operations.
Another option might be to draw the entire bitmap once into memory and then use a copy rectangle operation to transfer the image to the screen without drawing the full bitmap you have created. I think that copy rect should be a fast operation normally but if you are using it to draw the whole screen it seems like overkill and probably wont work as well.
你可能不会喜欢这个，但如果你所做的只是绘制方框和线条，那么画布的效率将会非常高。您是否遇到 UI 延迟或其他问题？
我搞乱的一件事是绘制子组件的集合，这些子组件不会对位图进行太大或根本没有改变，然后在画布上渲染（如果在正确的级别上进行缩放/移动并不那么昂贵）可以提高效率。我过去曾尝试创建一个框架来渲染现有较大图像的类似图块的子集，但没有取得太大成功。我已经让一切正常工作了，但代码却变得很难看。
哦，还有一个快速测试，看看您正在渲染的组件是否在屏幕创建的矩形内，可以节省大量的处理器时间。
You're probably not going to like this, but if all you're doing is drawing boxes and lines, the efficiency of the canvas is going to be pretty dang high. Are you getting UI lag or something?
One thing I have messed around with is drawing collections of subcomponents that won't change much or at all to a bitmap then rendering (scaling/moving aren't all that expensive if done at the right level) to the canvas can help efficiency. I have tried in the past to create a framework for rendering a tile-like subset of an existing larger image, but did not meet much success. I've made things work, but the code just gets ugly.
Oh, also a quick test to see if the component you are rendering is within the rectangle created by the screen can save you a bunch of processor time.