Bob wrote:
> I've done some careful testing. more than 60 iterations comparing
> 10.00.47 and 10.x (prototype).
That is essentially the path that I went down.
> The CPU usage is not in rendering, it's not in mouse or transformation
> manager routines that Bob messed up. It isn't statusManager doing nasty
> things. Check out the following data from Viewer.render1:
Agreed
> TEST #2: Let's get rid of all the graphics production
>
> void render1(Graphics g, Matrix3f matrixRotate, boolean antialias, int
> x,
> int y) {
> /*
> g3d.beginRendering(rectClip.x, rectClip.y, rectClip.width,
> rectClip.height,
> matrixRotate, antialias);
> repaintManager.render(g3d, rectClip, modelManager.getFrame(),
> repaintManager.displayModelIndex);
> g3d.endRendering();
> */
> Image img = g3d.getScreenImage();
> try {
> g.drawImage(img, x, y, null);
> System.out.println(x+" "+y);
> } catch (NullPointerException npe) {
> System.out.println("Sun!! ... fix graphics your bugs!");
> }
> g3d.releaseScreenImage();
> }
>
> RESULT: 0-2%CPU usage
> ANALYSIS: no surprise here; we aren't doing anything.
I don't understand why this is showing so little CPU.
You are still painting the image, even though it contains something.
> TEST 3: OK, how about no rendering?
>
> void render1(Graphics g, Matrix3f matrixRotate, boolean antialias, int
> x,
> int y) {
> g3d.beginRendering(rectClip.x, rectClip.y, rectClip.width,
> rectClip.height,
> matrixRotate, antialias);
> // repaintManager.render(g3d, rectClip, modelManager.getFrame(),
> // repaintManager.displayModelIndex);
> g3d.endRendering();
> Image img = g3d.getScreenImage();
> try {
> g.drawImage(img, x, y, null);
> } catch (NullPointerException npe) {
> System.out.println("Sun!! ... fix graphics your bugs!");
> }
> g3d.releaseScreenImage();
> }
>
> RESULT: 60-63% CPU
> ANALYSIS:
>
> Well, this was a surprise. Notice that there is no rendering being done
> at all. (That is, for the RECORD, none of my streamlined
> Viewer/TransformationManager methods are being accessed whatsoever.)
Bob, for the RECORD I never thought that it was your transformation code.
> The
> only significant Jmol code being excecuted differently between these two
> tests involve the following five methods:
>
> g3d.beginRendering();
> g3d.endRendering();
> g3d.getScreenImage();
> g.drawImage(img, x, y, null);
> g3d.releaseScreenImage();
>
> So please don't imply that it was something I did with the
> transformation manager and spin that brought this condition on.
Bob, I don't know what you think I said to imply that. I certainly did not
think that.
It was essentially impossible for any changes to the transformation
manager to have this effect. The matrices get calculated once at the
beginning of the paint cycle.
The fact that 'spin on' was broken was just unfortunate because it made it
more difficult to track down when the problem was introduced.
The problem was there *after* I did the rollback in r4818.
> I think it IS the Z-buffer being integers. For whatever
> reason, allocation of
> those buffers is just hugely costly.
Per the message that I sent out last nite, I don't think this is the problem.
> TEST #5. Effect of window size:
>
> dependence on image size: full spin, with rendered wireframe and balls,
> 1crn.pdb. spin Y 30.
>
> image size CPU
> 900x900 70-74%
> 800x800 66-71%
> 700x700 61-66%
> 600x600 60-62%
> 500x500 60-63%
> 400x400 35-45%
> 300x300 22-29%
> 200x200 10-14%
>
> Tell me this not the Z-buffer.
I don't think so.
> Here's what I think: Going to ints quadrupled the byte-size of the image
> allocation.
That is not true ... memory allocation went from 6 bytes per pixel to 8
bytes per pixe.
> Turns out that has a roughly quadruple effect on (some)
> CPUs. I'm betting that some "power" graphics PCs don't blink at this,
> but other more standard ones can just die in their tracks.
>
> How do I apply the z-buffer patch so I can try it myself with a short
> z-buffer?
cd trunk/Jmol
svn merge -r 5050:5051 https://svn.sourceforge.net/svnroot/jmol/trunk/Jmol/
Miguel
-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid0709&bid&3057&dat1642
_______________________________________________
Jmol-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jmol-developers
