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

Question

I'm developing in j2me and using canvas to drawing some images.

Now, my question is : what is difference of below sample codes in speed of drawing?

drawing after clipping area rectangle:

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

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

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

drawing without clip:

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

is the first one is faster? I'm drawing on screen a lot.

Answer 1

Well the direct answer to your question would be Mu I'm afraid - because you appear to approach the issue from the wrong direction.

Thing is, clipping API is not intended for performance considerations / optimizations. You can find full coverage of its purpose in API documentation (available online), it does not state anything related to performance impact:

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...

Attempting to use clipping API for imaginary performance considerations will make your code a nightmare to understand for future maintainers. Note this future maintainer may be you yourself, just few weeks / months / years later - I for one had my nose broken on my own code written some time ago without clearly understandable intent - trust me, it hurts the same as messing with poor code written by anyone else.

---

Don't get me wrong - there is a chance that clipping may have substantial performance impact in some particular case on specific device - why not, everything is possible given the variety of MIDP implementations. Know what? there is even a chance of it having an opposite impact on some other device, why not.

If (if) that happens, if (if) you'll somehow get a clear, solid, tested and proven justification of specific performance impact - then (then), go ahead, implement whatever tricks necessary to reach required performance, no matter how perverse they may be (BTDTGTTS). Until then, though, drop any baseless assumptions that just may come to your mind.

Until then... Just. Drop. It.

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)

Answer 2

This will almost certainly vary between platforms, and will depend on how much you're actually drawing.

I suggest you measure performance yourself by logging the number of paints per second, or the average duration of a paint method, and painting this on screen.

Answer 3

Drawing without clip should be faster on any platform for the simple reason that you are not calling two clip methods. But I might ask, why are you using clip to begin with?

You usually use clipping when you have an animation sprite or an icon variation in the same file. In this case you can create a file for each frame/icon. It will increase your jar file size and will use more heap space to hold these images on memory, but will be drawn faster.