Hi Brian,
That's a good question. Try using -Dsun.java2d.trace=log and going through the enormous amount of output it generates.
If you put little tags around the operation that you are worried about like
"println("About to do it!");" and "println("done!");" then you can find it
more easily and see what operations get invoked during that one call.If there is one line that looks like it is handling the source and destination formats just fine then you are probably set. If there are multiple lines describing multiple operations that look like it is creating and copying to a temporary image and then working from there then you can suspect that we probably don't support that operation directly...
...jim
--On Thursday, October 21, 2004 5:51 PM -0700 Brian Peterson <[EMAIL PROTECTED]> wrote:
Hi Jim,
You did answer a lot of my question -- thanks!
How can I tell if you have such a loop ready to handle the drawing? Or... What combination hints would maximize my changes of benifiting from such a loop?
Brian
-----Original Message----- From: Jim Graham [mailto:[EMAIL PROTECTED] Sent: Thursday, October 21, 2004 8:34 PM To: Peterson, Brian Cc: Discussion list for Java 2D API Subject: Re: [JAVA2D] clip area and drawImage
Hi Brian,
Obviously drawImage is not supposed to affect any destination pixels that are outside the clip area so I'm guessing that you are really asking if we make any stray reads of pixel data that ends up not contributing to the operation because the destination pixels that they map to get clipped?
If so then it depends on the operation. If we have a built-in loop that performs the designated blit with the designated attributes (composite, transform/scale, interpolation hint) then that loop will be pretty careful to only read the data it needs to write the unclipped destination pixels.
But, if we have no loop that performs the work directly then we fall into some general purpose workaround code that may do things like make a temporary copy of the source image in a format which we do have a direct worker loop for. If that is the case, then some attempt is made to limit the bounds of the image data that we convert into this temporary buffer, but we don't specifically determine every exact source pixel that we need based on the clip applied to the destination. In that caes we may end up reading (and processing) a few extra pixels that end up not contributing to the eventual imaging operation.
Also, if the destination is a window and that window is obscured by other windows then we may also process pixels that get thrown out by the obstruction. Our clipping optimizations in our rendering loops are mainly focused on pruning out work based on the clip that you specified in the Graphics object and we often rely on the system to do the clipping to the visible parts of the window on our behalf.
Did I answer your question or just create more confusion?
...jim
--On Thursday, October 21, 2004 10:09 AM -0700 Brian Peterson <[EMAIL PROTECTED]> wrote: > Will Graphics.drawImage(image, x, y, observer) copy only the image data > per the clip area for an non-accelerated image, or should I use a > different drawImage version to limit the number of bits passed down to > the graphics card (if this is even possible)? > > Brian
========================================================================= == To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff JAVA2D-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
=========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff JAVA2D-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
