android canvas绘图的效率

发布于 2024-09-28 06:00:04 字数 560 浏览 3 评论 0原文

我一直想知道画布是否有极限边界。

我的意思是如果我使用诸如drawline()、drawbitmap()、drawcircle()等函数, android 是否真的在画布上绘制了一些东西并浪费了一些 CPU 周期?

因为在所有的绘图功能之后,才决定了屏幕上实际打印的图片 通过屏幕尺寸。如果我在超出屏幕尺寸的东西上绘图,它就不会显示。

我想通过调用大量绘图函数在画布上做一些小细节,并使我的表面“bling bling”。如果超出范围,我不想使用它们,如果它们使我的绘图速度变慢。

我正在通过 SurfaceView 的结构开发一个小游戏,感谢您的建议。

例如:

我有一个机器人从<->步行b 在屏幕之外。

需要20个绘图函数才能在画布上绘制机器人行走的图片。 如果我滚动屏幕,我就能看到机器人。

那么如果屏幕外的绘图功能真的和屏幕上的绘图所花费的时间一样多。 我必须检测到,只有当用户可以看到机器人的位置时,我才能绘制。 否则,我不会。

如果绘图功能不会浪费太多CPU周期,那么即使当前屏幕看不到机器人,我每次也可以绘图。

I've been wondering if canvas has a limit boundary.

I mean if I use functions such asdrawline(), drawbitmap(), drawcircle(),
does android really draw something on the canvas and waste some CPU cycles??

because after all the drawing functions, the actual picture print on the screen is decided
by the screen size. And if I draw on something that is out of screen size, it doesn't show up.

I want to do some small detail on my canvas by calling lots of drawing functions and make my surface "bling bling". If it is out of bound I don't want to use them, if they make my drawing slow down.

I am working on a little game by the structure of surfaceview, Thanks for any advice.

for Example:

I have a robot walking from a <-> b OUTSIDE the screen.

it takes 20 drawing functions to draw a robot walking picture on the canvas.
If I scroll the screen, then I can see the robot.

So if the drawing function outside the screen really takes as much time as draw on screen.
I have to detect that only if the robot's position can be seen by the user, then I draw.
otherwise, i don't.

if the drawing function doesn't waste much CPU cycles, then I can just draw everytime even if the current screen cannot see the robot.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

萌无敌 2024-10-05 06:00:04

当画布覆盖整个屏幕时,可以加快画布绘制速度的另一件事是使用没有背景的主题。默认主题至少有一个可绘制的彩色背景,当您将视图放在其之上时,即使您的视图填满整个屏幕,也会导致绘制时间变慢。

使用主题,例如:

    <style name="Theme.NoBackground" parent="android:Theme">
        <item name="android:windowBackground">@null</item>
    </style>
</resources>

Romain Guy 在 http://www.curious-creature.org/2009/03/04/speed-up-your-android-ui/

Another thing that can speed up canvas drawing when your canvas covers the entire screen is to use a theme that has no background. The default theme has at least a color background drawable and that results in slower draw times when you put your views over top of it, even if your view fills the whole screen.

use a theme such as:

    <style name="Theme.NoBackground" parent="android:Theme">
        <item name="android:windowBackground">@null</item>
    </style>
</resources>

Romain Guy has a great description of this phenomenon at http://www.curious-creature.org/2009/03/04/speed-up-your-android-ui/

Smile简单爱 2024-10-05 06:00:04

你的画布由位图(2D)或openGL(3D,我没有经验)支持。画布上的所有绘图都会被剪切到剪切矩形,您可以放大、缩小剪切矩形、与新矩形或路径相交等。因此,在绘制到画布上之前,您确实需要管理剪切矩形,特别是如果它有一个大的位图。如果您剪切到等于屏幕尺寸的区域,您将节省 CPU 周期。如果您的游戏是卷轴类型游戏,您可以剪辑到大于屏幕尺寸的区域并平移,偶尔在屏幕外绘制以更新屏幕上的区域。如果您的游戏在各个方向上无限滚动,那么您将需要多个较小的画布,您可以将它们绘制到主中央画布周围,并根据滚动游戏的方向从左到右、从上到下翻转它们。对于小型设备来说,带有一张画布的大位图可能会占用太大的内存空间。

Your canvas is backed by your bitmap (2D), or openGL (3D,which I have no experience with). All drawing on your canvas is clipped to the clipping rectangle, which you can grow, shrink, intersect with new rectangles or paths, etc. So, you really want to manage your clipping rectangles before you draw into your canvas, especially if it's backed by a large bitmap. If you clip to a region that's equal to the screen size you will save CPU cycles. If your game is a scroller type game, you can clip to a region larger than the screen size and pan around, drawing offscreen occasionally to update the area that's coming onto the screen. if your game has infinite scrolling in all directions then you'll want to have multiple smaller canvases that you can draw into all around your main central canvas, and flip them around left to right, top to bottom depending on the directions of your scrolling game. One large bitmap with one canvas might have too big of a memory footprint for a small device.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文