Question

我正在开发j2me并使用画布绘制一些图像。

现在，我的问题是：下面的示例代码在绘图速度方面有什么不同？

剪裁区域矩形后绘制：

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），它没有说明与性能影响相关的任何内容：

剪辑

剪辑是Graphics对象目标中的一组像素，可以通过图形渲染操作进行修改。

每个Graphics对象都有一个剪辑。图形操作修改的唯一像素是位于剪辑内的像素。剪辑外的像素不会被任何图形操作修改。

提供操作以使当前剪辑与给定矩形相交并直接设置当前剪辑...

尝试使用剪辑API进行虚构的性能考虑将使您的代码成为未来维护者理解的噩梦。请注意，这个未来的维护者可能是你自己，只是几个星期/几个月/几年后 - 我的一个人在我前面写的自己的代码上没有明显可理解的意图 - 相信我，它会伤害我的鼻子与搞乱其他人写的糟糕代码一样。

不要误解我的意思 - 在特定设备的某些特定情况下，削波可能会对性能产生重大影响 - 为什么不呢，鉴于各种MIDP实现，一切都是可能的。知道什么？甚至有可能它与其他设备产生相反的影响，为什么不呢。

如果（ if ）发生，如果（ if ），您将以某种方式获得明确，可靠，经过测试并证明具体性能影响的理由 - 那么（<强大>然后），继续，实现达到所需性能所需的任何技巧，无论它们有多么不正常（BTDTGTTS）。不过，在此之前，你可以放下任何毫无根据的假设。

直到那时......只是。下降。它

开发人员喜欢优化代码并且有充分的理由。它是如此令人满意和有趣。但是知道何时优化更为重要。不幸的是，开发人员一般都有可怕的直觉关于应用程序中的性能问题实际上会在哪里......大多数性能调整让我想起了那个在厨房里寻找钥匙的人的老笑话，尽管他在街上失去了他们，因为厨房里的灯光更好......（Brian Goetz）

Answer 2

这几乎肯定会因平台而异，并取决于您实际绘制的数量。

我建议您通过记录每秒的油漆数量或油漆方法的平均持续时间来自行测量性能，并在屏幕上绘制。

Answer 3

没有剪辑的绘图在任何平台上应该更快，原因很简单，因为你没有调用两个剪辑方法。但我可能会问，你为什么要用剪辑开头？

当您在同一文件中有动画精灵或图标变体时，通常会使用剪裁。在这种情况下，您可以为每个帧/图标创建一个文件。它将增加你的jar文件大小，并将使用更多的堆空间将这些图像保存在内存中，但会更快地绘制。

j2me：'g.clipRect（）'对速度的影响是什么？

3 个答案:

剪辑