performance - j2me : what is effect of 'g.clipRect()' on speed?

Question

我正在j2me中进行开发并使用canvas来绘制一些图像。

现在，我的问题是:下面的示例代码在绘图速度上有什么区别？

剪切区域矩形后绘制:

g.clipRect(x, y, myImage.getWidth(), myImage.getHeight());

g.drawImage(myImage, x , y, Graphics.TOP | Graphics.LEFT);

g.setClip(0, 0, screenWidth, screenHeight);

没有剪辑的绘图:

g.drawImage(myImage, x, y, Graphics.TOP | Graphics.LEFT);

第一个更快吗？我经常在屏幕上画画。

Answer 1

那么你的问题的直接答案是 Mu我担心 - 因为你似乎从错误的方向处理这个问题。

事实是，剪辑 API 并非用于性能考虑/优化。您可以在 API 文档 ( available online ) 中找到其用途的完整介绍，它没有说明与性能影响相关的任何内容:

Clipping

The clip is the set of pixels in the destination of the Graphics object that may be modified by graphics rendering operations.

There is a single clip per Graphics object. The only pixels modified by graphics operations are those that lie within the clip. Pixels outside the clip are not modified by any graphics operations.

Operations are provided for intersecting the current clip with a given rectangle and for setting the current clip outright...

出于想象中的性能考虑而尝试使用裁剪 API 将使您的代码成为 future 维护人员难以理解的噩梦。请注意，这个 future 的维护者可能就是你自己，就在几周/几个月/几年后 - 我就因为前一段时间编写的自己的代码而没有清晰可理解的意图而被打断了 Nose - 相信我，这很痛苦就像乱搞其他人编写的糟糕代码一样。

---

不要误会我的意思 - 在特定设备上的某些特定情况下，剪辑可能会对性能产生重大影响 - 为什么不呢，考虑到 MIDP 实现的多样性，一切皆有可能。知道什么？它甚至有可能对某些其他设备产生相反影响，为什么不呢。

如果(如果)发生这种情况，如果(如果)您能以某种方式获得明确、可靠、经过测试和证明的具体性能影响的理由 - 那么(<强>然后)，继续，实​​施达到所需性能所需的任何技巧，无论它们有多么反常( BTDTGTTS )。不过，在那之前，请放弃您可能想到的任何毫无根据的假设。

直到那时...就这样。降低。它。

Developers love to optimize code and with good reason. It is so satisfying and fun. But knowing when to optimize is far more important. Unfortunately, developers generally have horrible intuition about where the performance problems in an application will actually be... Most performance tuning reminds me of the old joke about the guy who's looking for his keys in the kitchen even though he lost them in the street, because the light's better in the kitchen... (Brian Goetz)