I was pondering the same question. I've noted that setting pixels via the data buffer directly is 10x !!! faster than going through setRGB() on my machine (I have a 2.4Ghz P4 with top of the line ATI graphics card [windows]). I had thought that it was just code overhead in the layers or would the differential between cache/DRAM vs VRAM be that significant?
If I am going to be writing pixels across a buffered image on, say, 1 in 5 renders does it ever make since to use setRGB() at 1/10th write perf? Is there a good guide to the performance differences for accelerated and unaccelerated operations? Kind of feeling around in the dark with this stuff, would be good to know more about what is going on underneath to make better rendering decisions ... -- Jonathan Shore Derive Inc -----Original Message----- From: Discussion list for Java 2D API [mailto:[EMAIL PROTECTED] On Behalf Of Chet Haase Sent: Friday, April 02, 2004 10:14 AM To: [EMAIL PROTECTED] Subject: Re: [JAVA2D] TransAccel Hi Mik, A simple question about a relatively complicated subject... You have tripped upon the internal "rasterStolen" variable that we use to detect when someone has accessed the Raster/DataBuffer of a managed image. We can accelerate managed images only when we know exactly what is going on with the main copy of that image. That is, if we can detect when that main copy changes, then we know when to update our accelerated cache of that image. But the API you are using to access the pixels (getDataBuffer()) defeats this approach because we can no longer detect when the main copy has changed. That is, when you have array access into the pixel data, we cannot easily detect when you change values in the array, thus we cannot know when the original copy has changed and our cached version nees to be updated. So we punt. There may be better ways for us to manage this internally in the future, but for now we simply detect the case where someone has gotten direct access to the pixel data and turn off acceleration for that image. The best ways to access the data in a managed image without causing this punt are any methods that render to the image without returning the data buffer. This includes the setPixel methods in Raster and the setRGB methods in BufferedImage; both of these change the data without giving you arbitrary access to the data, so we can detect that the data has changed and update the cached/accelerated image appropriately. Another approach is to render to a different image (perhaps a translucent or transparent one) and then use drawImage() to copy the data in. Finally, you can always use the standard rendering primitives to tweak the data (drawLine(), fillRect, etc.). None of these may be the fastest in the world for setting pixel data, but at least they will allow you to set the data without defeating acceleration. The current state of hw accelerated images is that they work well for static data, but are suboptimal for dynamic data. This is just a result of the kinds of things we needed to accelerated first in our long road toward full-on hw acceleration of everything. The approach you use in your app depends on the performance tradeoff between changing the pixel data in the image versus copying those images to some accelerated surface (e.g., the back buffer). For some applications, it might work out better to have dynamic sprites/images in software because our read/write access to that data is much faster than when those images are stored in VRAM. But if you are not changing those sprites/images too frequently, then you will probably do better by leaving them in VRAM so that they benefit from the hw accelerated copy operations. As always, benchmark if you need to know the Right Answer for your situation. Chet. Michele Puccini wrote: > Hello, > > a simple question: > > I tried to access the pixels directly through Raster->DataBufferInt > but as soon as I call: > > DataBufferInt dbi = (DataBufferInt)(wr.getDataBuffer()); > > the image becomes non accelerated and there's apparently no way to > re-accelerate it. > > > I also noticed that setting the raster pixels with: > > raster.setPixel(x,y,a,r,g,b); > > works, but I suppose this solution gives very low performance. > > so the question is: which is the bset way to change the pixels of an > accelerated (managed) image on the fly ? > > Cheers, > > Mik of ClassX > ====================================================================== > ====== > >>ClassX Development Italy Via Francesca, 463 I-56030 Montecalvoli (PI) < >>Tel.(+39)-0587-749206 Fax.(+39)-0587-749206 WEB: >>http://www.classx.it < > > ====================================================================== > ====== > > ====================================================================== > ===== > 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". =========================================================================== 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".
