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

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.

Solution

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)