> is it normal that the rendering time about scales 1 to 1 with the > window size?
Good observation > would have thought that the rendering was mostly determined by > the number of atoms on screen, instead of the number of pixels... The short answer is 'Yes, it is linear' The long answer is ... probably longer than you expected :-) At this point, we are effectively not using *any* of the java graphics routines. All the rendering of all the shapes is being done by our own routines in our own code. This is necessary because the graphics primitives need to pay attention to the z dimension (by using the zBuffer) to decide whether or not a pixel should be painted. The rendering cycle is triggered by a call to update()/paint() and can be broken down as follows: 1. clear the offscreen buffer 2. render the entire scene into the offscreen buffer 3. draw the offscreen buffer to the screen I am going to talk about the first and third steps, then come back to the second step, because it is a bit more complicated and more interesting. Step 1. Clearing the offscreen buffer ------------------------------------- The offscreen buffer is actually two buffers, a pixelBuffer and a zBuffer. The pixelBuffer is an int[] which contains ARGB values for the pixels. The zBuffer is a short[] which contains the current z-depth of the associated pixel. The size of these buffers is width*height of the current window. When the window size changes the pixelBuffer and zBuffer get reallocated. The process of clearing each of these arrays is simply filling them up with the same value. Each entry in the the pixelBuffer is set to the ARGB value of the current background color. Each entry in the the zBuffer is set to be 'infinitely far away'. This is clearly a linear function of the array size ... if the arrays are twice the size it will take twice as long to fill them up. [The step of clearing these buffers not normally the dominant step in the paint cycle. Nevertheless, the time is *not* insignificant. For a window 316x316 you have 100K pixels. So the pixelBuffer is 4x100K=400Kb and the zBuffer is 2x100K=200Kb. If the scene that you are rendering is a wireframe image then you may only touch a few thousand of those pixels ... a few percent. But regardless of how few pixels are modified, you still have to clear the entire pixelBuffer and zBuffer *every* paint cycle.] Step 3. java.awt.Graphics.drawImage() ------------------------------------- After the scene is rendered, the entire pixelBuffer is sent to the screen with one drawImage operation. The image is the exact size of the screen, so there is no rescaling or clipping required. (The zBuffer is not involved at this point.) Each pixel in the image must be picked up, probably manipulated a little, then transferred to video memory. Potentially some of this could be offloaded to the video card. This is clearly a linear operation depending upon the number of pixels in the image ... the size of our int[] pixelBuffer. [This would seem to be a simple operation, and an important operation that would have received a lot of attention and optimization. Unfortunately, my impression is that the implementation on my Linux box is slow. I think that within the jvm the image *must* be being copied more than once ... and these images are 500Kb and up. Sun would probably place some of the blame on X Windows, but I feel quite certain that Java is noticably slower than if I did an equivalent 'drawImage' operation from C code.] Step 2. Scene Rendering ----------------------- So, the entire scene needs to get rendered into our int[] pixelBuffer. The code must iterate over all of the graphics shapes (atoms, bonds, labels, etc.). Each of these shapes generates a set of pixels. Each of these pixels has <x,y,z> coordinates. The z coordinate of each these pixels must be tested against the corresponding zBuffer entry at <x,y>. If this pixel is closer to the user than the current zBuffer entry then the corresponding <x,y> value in the pixelBuffer is updated. Even relatively small spheres and cylinders involve hundreds of pixels. Each of these pixels needs to be tested against the current zBuffer value to see whether or not it is in front of the current pixel. And this is where all the time is spent. And you can convince yourself that this process is linear ... if the int[] pixelBuffer is twice as big then we are going to generate twice as many pixels and it will take twice as long to fill it up. This by itself does *not* imply that all windows of the same size will have the same rendering time. But one can easily see that for a given configuration of graphics shapes, for a given scene, if you blow it up to twice the size then you will have twice as many pixels and it will take twice as long to construct the same scene. However, for our molecular models it probably *is* the case that the rendering time is almost independent of the model (for a given rendering style). Because of the auto-scaling, if you load up a model with only a few atoms then you get a few big atoms. If you then load up a model with lots of atoms then you get lots of small atoms. But the 'percentage of coverage' or 'pixel density' is probably about the same. You get a much more profound effect if you change the size of the atoms by using 'spacefill on'. Because now you have dramatically increased the pixel density of the scene and there is a lot more testing and setting of pixels at the bottoms of our iterators. So, we have three steps. The first and third steps are clearly linear functions of the size of the int[] pixelBuffer ... the window size. And, while the second step is more complicated, it also is linear. One more thing to remember. If you make your window 2 times wider and 2 times higher then you have made it 4 times as big. Miguel ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php _______________________________________________ Jmol-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jmol-developers
