Performance Hit.

[Username]

I have a program that repeatedly invokes "sun.java2d.loops.GraphicsPrimitiveMgr$2.compare(object, object)" - millions of times.  The program uses custom painted components and at times uses BufferedImages of  TYPE_4BYTE_ABGR, and uses transparent colors.  The methods that paint the components are not invoked many times, yet this "sun.java2d.loops.GraphicsPrimitiveMgr$2.compare(object, object)" method is constantly invoked.
Please help with ideas.

[Jeff]

Um are you invoking that method directly yourself?

if so then dont.  Nothing in the sun.* packages are intended to be called directly by user code.

If this is the result of a performance trace of normal Java code then please give us the entire trace to see what is being called and why.

[Username]

no I am not invoking them myself.  They are being invoked somewhere in the Java2D implmentation.  There was a previous post about this in the forum at: http://www.java-gaming.org/forums/index.php?topic=2396.msg22655#msg22655 but with no solution.

Games published by our own members! Check 'em out!

[trembovetski]

I have a program that repeatedly invokes "sun.java2d.loops.GraphicsPrimitiveMgr$2.compare(object, object)" - millions of times.  The program uses custom painted components and at times uses BufferedImages of  TYPE_4BYTE_ABGR, and uses transparent colors.  The methods that paint the components are not invoked many times, yet this "sun.java2d.loops.GraphicsPrimitiveMgr$2.compare(object, object)" method is constantly invoked.
Please help with ideas.

Whatever performance hit you're seeing is not because of the GraphicsPrimitiveMgr.compare() calls
but because of the unusual image type you're using. We don't have many loops for this type,
so we have to convert it to an intermediate image of type INT_ARGB first and then one more time INT_ARGB to the destination type.

Do you really need this image type? INT_ARGB will be much faster. Also, if you don't need translucency,
INT_RGB will be even better.

Thanks,
  Dmitri

[Username]

I changed the type to    TYPE_INT_ARGB but the result is the same.  The application is still slow and uses up 90% of my CPU.  All I am doing is painting a custom component into a BufferedImage, and then painting the buffered image out to the graphics context using Graphics2D.paintImage().

[princec]

That's because painting to BufferedImages is reasonably likely to not be hardware accelerated, and paintng BufferedImages to video graphics contexts is also reasonably likelt to not be hardware accelerated. You should consider using createCompatibleImage at least to get your graphics in the correct format for the destination graphics context.

Cas

[Username]

That's because painting to BufferedImages is reasonably likely to not be hardware accelerated, and paintng BufferedImages to video graphics contexts is also reasonably likelt to not be hardware accelerated. You should consider using createCompatibleImage at least to get your graphics in the correct format for the destination graphics context.

Cas

I tried that but it didn't work.  I however, did find the problem.  I was asking the custom component's parent to repaint itself after I finished painting the custom component.  This caused an implicit loop since the parent's repainting caused all of its children to be repainted.

[princec]

I'd still bear my suggestion in mind as it can make your graphics paint an order of magnitude faster.

Cas