Oleg... I doubt I can post to java3d since I'm not a subscriber, so if you would, please forward this on.
>>Has anyone tried using JAI to render dynamic texture images? I did get >>something working tonight, the code *looks* great (nice modular 2D rendering >>graph, etc.) but the performance is disappointing. >> >>On my machine, repeatedly rendering a static 256x256 BufferedImage texture >>using an updateData call, I get >=200 FPS. If I write a simple JAI graph >>(scale, then smooth for example) and draw the produced RenderedImage into >>the BufferedImage for display, my frame rate drops to 50 FPS. >> >>It appears that JAI is more suited to larger images and more heavy-weight >>processing (where perhaps a memory copy across JNI is less of a factor?). >>Anyone else have any experience with this? With such a drop in frame-rate I >>may be able to implement the rendering operations by hand in Java more >>efficiently, but I'd really prefer not to! Two things come to mind. First, what kind of SampleModel is being used for the static BufferedImage, and by the JAI image? It's been our experience that Java3D really likes certain kinds of sample models and is really unhappy with others. I wouldn't be too surprised if that could cause a 4x slowdown. You can verify this by printing out what SampleModel JAI is returning, creating a static BufferedImage using that same SM, and rerunning the static test. If that is the problem, you can supply RenderingHints to JAI that will cause it to use a different SampleModel. It should be sufficient to attach the hint on the last node in the JAI chain, but experiment with putting it on every node too; that might make an efficiency difference when JAI actually computes the chain (good or bad, I can't say! ;-} ). Second, are you using the JAI tile cache? If so (and that's the default), requests for the image should result in a cache hit with no computation, assuming the image parameters don't change. If you don't disable the cache, and don't change the JAI parameters, and you're still getting a slowdown, it really points at a SampleModel issue (BTW, check the ColorModels too). Of course, any time you *change* a parameter to JAI, the image must be recomputed, and that will take some amount of time. If the SM's and CM's match, and the cache is on, the only time you should get a slowdown is when a JAI parameter changes. BTW, if you change a parameter to a JAI parameter block, it sends RenderingChangeEvent's down the chain. Your code that hooks the JAI image to Java3D could take advantage of that and do something to Java3D whenever the image changes. Or, if you simply ask for the image data each time through the rendering loop, you'll automatically get the new image next time through after the change. If you need to mess with the JAI tile cache, Dennis Sigel posted a really neat cache monitoring tool a couple of weeks ago. Check the JAI interest group archives. -Bob Deen @ NASA-JPL Multimission Image Processing Lab [EMAIL PROTECTED] -- =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff JAVA3D-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
