Hi Julian,
> Can you suggest a way (or a program) to objectively measure the speed
> of copying an image from memory to the screen? In a later message, you
> mentioned that you were getting 30M pixels/sec and it would be interesting
> to compare the results I get with what you found.
I wrote a program to produce an image of a particular format and then
did a tight loop executing nothing but drawImage calls. I then divided
the time taken by the number of operations times the number of pixels
in the image.
> Although the impression I get from watching Photoshop 5 load and display
> an image (jpeg format, 1280x1024x24) seems faster than a second, there
> is no programmatic way to accurately measure how fast it is completing
> the process.
In this case you are throwing in the decode of the JPEG, the massaging
of the pixels into whatever internal format that Photoshop wants to use,
and finally the blit to the screen. I was measuring just blits.
> We still use a rather dated application (written around 1994) called
> ScriptX for some of our work. ScriptX can load, decode and display
> the previously specified image on the same hardware in less than .75
> seconds.
Same comment above about measuring more than just the blit speed. Did
you try this same experiment using Java?
> A cursory look at the .exe reveals lots of calls to GetDIBits(),
> SetDIBits() and CreateCompatibleBitmap(). Because of this, I suspect
> it is able to take advantage of hardware acceleration if it is present
> on the system's graphics card.
CreateCompatibleBitmap() is the GDI call that is most likely to produce
an image that lives on the card, but most difficult to get the pixels
in and out of it.
> After reading the description about the various methods of interfacing
> Java2D with the Win32 GDI, I have a question: Why is it such a problem
> if you lose the ability to access the pixels directly by using the
> CreateCompatibleBitmap() family of APIs?
1. We can't draw on the image (Image.getGraphics())
2. We can't use the image as a source for filters
3. We can't even transform the image (essentially a filter operation)
4. The getRGB() getPixelData() etc. methods on BufferedImage, Raster,
et al don't function.
Of course, with CreateCompatibleBitmap() we don't completely use the
ability to access the pixels, we just have to copy them in and out
using GDI functions.
If we are only interested in drawing simple shapes and blitting the
image to the screen (with simple rectilinear scales), then we can
use CreateCompatibleBitmap() and do everything through GDI as we did
in JDK 1.1.
In order to do the more advanced 2D operations which go way beyond
the capabilities of GDI and JDK 1.1, we need to access the image
pixels directly.
> It seems like if you have to use the Win32 GDI as a filter for all
> pixel access, the hardware acceleration provided by most graphics
> cards used today (with Windows at least) will more than make up for
> the extra processing time that is required to interface with it.
It depends on the operation. If GDI can perform the operation we
want by itself, then it is a win-win situation. If we have to punt
and do our own pixel manipulation then the GetPixel/SetPixel (or
GetDIBits/SetDIBits) operations would swamp everything. Software
blits are only 4-5x slower than hardware blits and the total time
taken is not the majority of most applications' rendering needs.
If each rendering call takes 2x as long but the blit goes 4x as
fast then the overall difference depends on how many rendering
calls there were.
To be sure - we have prototype implementations of 2D that beat 1.1
on some Swing benchmarks even without hardware acceleration. Some
of the parts of that benchmark that are blit-limited go faster with
1.1, but other parts that do other rendering more go faster on the
prototype. When we solve the API dilemma of how to get the pixels
on the display card without giving Windows permission to throw them
out at its will, we can get the best of both worlds...
...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".
