Hello Jim thank you for your reply. Sincerely, the code I'm using for the image transform is not mine, Jerry Huxtable did me the favour to pass it to me. Though, I checked the code in detail, and it does not seem to be any improvements that can be made. (considering your advices). I also want to tell you, that, when this transform code is ran, another calculations are made besides this code, so the processor is not 100% available for this transformation. (another geometric calculations are made to refresh some lines and pies). I've been thinking about some solutions, and the most applicable to my case, I think would be the native method invocation. Insert this tranformation into a dll, and call it from JAVA. Which actually I have the C++code. After all, is what you guys do with the JAI api right?
The only thing that bothers me is that is not possible to call a dll that is inside a cab/jar, as far as I know. So it seems that I'll have to sign the applet in order to enable it to write this dll file to the local machine. Anyway, I need to consult this with my co-workers once I get back to Japan. (right now I'm taking a vacation in my home country). happy new year. regards, Jonathan ----- Original Message ----- From: "Jim Graham" <[EMAIL PROTECTED]> To: "Jonathan Sosa" <[EMAIL PROTECTED]> Cc: "Discussion list for Java 2D API" <[EMAIL PROTECTED]> Sent: Wednesday, January 02, 2002 3:34 PM Subject: Re: [JAVA2D] irregular image resize > Hi Jonathan, > > If you can't use Java 2 APIs (introduced in version 1.2) then there are > going to be performance losses with having to deal with the ImageConsumer > and ImageProducer system, but there's not anything you can do about that. > (We created BufferedImages in 1.2 to facilitate the kinds of things that you > are trying to do.) > > I'd say that 57,600 array accesses per refresh should be reasonably within > a good JIT's capabilities on any recent computer (say Pentium 3 or better). > It may be that with the overhead of the ImageSource having to feed the > pixels to the Image object that it pushes you over the edge. A couple of > things might be making different parts of this worse: > > - What kind of ColorModel are you using? The default would be best if you > have int pixels and need alpha (which you presumably do to get the non-rect > image outline). The same ColorModel without alpha (i.e. the same red, > green, and blue masks) would be best if you can get away without alpha (i.e. > if you have a constant background color you could use). > > - What does your inner loop look like? Maybe there are some inefficiencies > that are cropping up there. Many of the same rules of writing efficient > C code apply to Java as well, but there are some unique gotchas. Such as: > > - Java requires array bounds checking on every array access so > try to use only one array load and store per inner loop: > > // inefficient > dst[i] = r << redmask; > dst[i] += g << grnmask; > dst[i] += b << blmask; > > // better > dst[i] = (r << redmask) + (g << grnmask) + (b << blmask); > > (Work is being done in HotSpot to reduce array bounds checks, > but it isn't yet up to the task that image processing loops > tend to need and I don't know of any 1.1 JITs that did this.) > > - Java has strict memory access requirements. If you use a > member field in the inner loop, copy it to a local variable > if you know it won't change (or if you want to protect yourself > from changes). This saves a field access per iteration. > > Other tips and tricks may apply, but those are common pitfalls that I > can think of... > > ...jim =========================================================================== 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".
