From: mth <mt...@mt...> - 2002-10-27 21:34:30
|
I checked in some changes which improve redisplay/rotation performance. Basic approach is to use integer variables for screen coordinates instead of Point3f objects. This allows operations without generating/discarding objects. Should be no visible changes to functionality. mth Detail ------ I have spent time over the past week looking at display performance of jmol during rotations. I just checked in the first set of changes to address this. Over the next few days I plan on checking in a few more sets of performance enhancements. On larger molecules jmol has some significant performance problems. It can easily take several seconds to paint a frame. Even on smaller molecules, the garbage collector kicks in frequently, causing annoying jerkiness during mouse-rotations. To collect timings I put some code into ChemFrameRenderer.paint() which uses System.currentTimeMillis() to log the times to the console. I chose to work with a .pdb file of 1979 atoms, 434 CRO protein complex. The timings shown below were taken with Java sdk 1.4.0_01 under Redhat 8.0 on a 1 Ghz Celeron. All the references to screen coordinates are similar to int x1 = (int) atom1.getScreenPosition().x int y1 = (int) atom1.getScreenPosition().y int z1 = (int) atom1.getScreenPosition().z The implementation of getScreenPosition returns a new Point3f each time the method is called. The coordinates are accessed when working with the atom, but also when working with the bonds and atom labels. The z coordinate is also used repeatedly during the sort process. Therefore, probably 10-20 (?) Point3f objects are being created and immediately discarded for each atom in the molecule during each repaint operation. I changed the code to add public integer variables to the Atom class. These integer variables can be accessed directly without generating lots of objects. In addition, I switched the sort to use java.util.Array.sort. (As a minor note, the comparisons are now based upon integers instead of doubles.) The times are now as follows: numbers are approximate averages of what gets generated: before after transform to screen coordinates 2 ms 2 ms sort 340 ms 25 ms render wireframe 80 ms 70 ms quickdraw atoms & bonds 250 ms 200 ms shadowed atoms & bonds 3200 ms 2950 ms total paint() time wireframe 425 ms 100 ms quickdraw 575 ms 225 ms shadowed 3500 ms 3000 ms |
From: Egon W. <eg...@sc...> - 2002-10-28 09:49:43
|
On Sunday 27 October 2002 22:34, mth wrote: > I checked in some changes which improve redisplay/rotation performance. > Basic approach is to use integer variables for screen coordinates instead > of Point3f objects. This allows operations without generating/discarding > objects. > Should be no visible changes to functionality. I've found a bug. When looking at samples/dna.xyz, choosing Display->Wire Frame Rotation, I get this: Rotating slowly sometimes make the bonds disappear temporarily, until a drag further. Rotating fast make the complete structure disappear perminantly, i.e. all atoms are from now on located in the origin (0,0)... opening e new file does not solve this, and then too all atoms are located in the origin. Could you please have a look at this? It might be difficult, as it seems to be a timing issue, which is harder to locate on faster machines... I use a Pentium II, 300 Mhz. > Detail > ------ > I have spent time over the past week looking at display performance of > jmol during rotations. I just checked in the first set of changes to > address this. Over the next few days I plan on checking in a few more > sets of performance enhancements. > > On larger molecules jmol has some significant performance problems. It > can easily take several seconds to paint a frame. Even on smaller > molecules, the garbage collector kicks in frequently, causing annoying > jerkiness during mouse-rotations. > > To collect timings I put some code into ChemFrameRenderer.paint() which > uses System.currentTimeMillis() to log the times to the console. I chose > to work with a .pdb file of 1979 atoms, 434 CRO protein complex. The > timings shown below were taken with Java sdk 1.4.0_01 under Redhat 8.0 on > a 1 Ghz Celeron. Could you add this file to samples/ ? > All the references to screen coordinates are similar to > int x1 = (int) atom1.getScreenPosition().x > int y1 = (int) atom1.getScreenPosition().y > int z1 = (int) atom1.getScreenPosition().z > > The implementation of getScreenPosition returns a new Point3f each time > the method is called. The coordinates are accessed when working with the > atom, but also when working with the bonds and atom labels. The z > coordinate is also used repeatedly during the sort process. Therefore, > probably 10-20 (?) Point3f objects are being created and immediately > discarded for each atom in the molecule during each repaint operation. > > I changed the code to add public integer variables to the Atom class. > These integer variables can be accessed directly without generating lots > of objects. > > In addition, I switched the sort to use java.util.Array.sort. (As a minor > note, the comparisons are now based upon integers instead of doubles.) > > The times are now as follows: > > numbers are approximate averages of what gets generated: > before after > transform to screen coordinates 2 ms 2 ms > sort 340 ms 25 ms Ah, that is an interesting increase. > render > wireframe 80 ms 70 ms > quickdraw atoms & bonds 250 ms 200 ms > shadowed atoms & bonds 3200 ms 2950 ms > > total paint() time > wireframe 425 ms 100 ms > quickdraw 575 ms 225 ms > shadowed 3500 ms 3000 ms Do you have a script to calculate these numbers? Can you send it to this list? BTW, you seem to be much into computer graphics. In the end I want to port Jmol to CDK, but am not that good in computer graphics. Could you write up an outline on the algorithm Jmol uses to generate an image? I.e. the complete process of 3D coordinates in the file to screen coordinates in the JPanel frame? Egon |
From: mth <mt...@mt...> - 2002-10-28 10:21:20
|
> I've found a bug. When looking at samples/dna.xyz, choosing > Display->Wire Frame Rotation, I get this: > ... > Could you please have a look at this? It might be difficult, as it seem= s > to be a timing issue, which is harder to locate on faster machines... = I > use a Pentium II, 300 Mhz. > Egon, I've spent some time trying to reproduce the problem ... no luck ... as you suspected. I reviewed the bond rendering source code to double-check that I wasn't losing precision when casting from ints to doubles during the bond perspective calculations. I didn't see anything. It is interesting that you state that you can lose the entire molecule. Sorry, since I can't reproduce the bug I am at a loss. I can get access t= o a Mac G3 300 Mhz, but not until tomorrow. Suggestions? Miguel -------------------------------------------------- Miguel Howard mi...@ho... c/Pe=F1a Primera 11-13 esc dcha 6B 37002 Salamanca Espa=F1a Spain -------------------------------------------------- telefono casa 923 27 10 82 movil 650 52 54 58 -------------------------------------------------- To call from the US dial 9:00 am Pacific US =3D home 011 34 923 271 082 12:00 noon Eastern US =3D cell 011 34 650 525 458 6:00 pm Spain -------------------------------------------------- |
From: Egon W. <eg...@sc...> - 2002-10-28 12:23:26
|
On Monday 28 October 2002 11:21, mth wrote: > > I've found a bug. When looking at samples/dna.xyz, choosing > > Display->Wire Frame Rotation, I get this: > > > Could you please have a look at this? It might be difficult, as it seems > > to be a timing issue, which is harder to locate on faster machines... I > > use a Pentium II, 300 Mhz. > > I've spent some time trying to reproduce the problem ... no luck ... as > you suspected. > > I reviewed the bond rendering source code to double-check that I wasn't > losing precision when casting from ints to doubles during the bond > perspective calculations. I didn't see anything. > > It is interesting that you state that you can lose the entire molecule. > > Sorry, since I can't reproduce the bug I am at a loss. I can get access to > a Mac G3 300 Mhz, but not until tomorrow. Would be nice if you could try to reproduce it on the Mac... maybe I can generate some debugging info... what debug messages do you need? Egon |
From: Miguel H. <mi...@ho...> - 2002-10-29 07:57:39
|
> I've been testing the samples/ files with the CVS version... then I > realized that I could live with the problem in the next release, *if* > loading a new file would reset the screen coordinates... now the becom= e > zero at a yet unknown event, and then stay zero... if they would be > reset to a non-zero I am sorry, I do not understand what you mean by "the screen coordinates become zero". -------------------------------------------------- Miguel Howard mi...@ho... c/Pe=F1a Primera 11-13 esc dcha 6B 37002 Salamanca Espa=F1a Spain -------------------------------------------------- telefono casa 923 27 10 82 movil 650 52 54 58 -------------------------------------------------- To call from the US dial 9:00 am Pacific US =3D home 011 34 923 271 082 12:00 noon Eastern US =3D cell 011 34 650 525 458 6:00 pm Spain -------------------------------------------------- -------------------------------------------------- Miguel Howard mi...@ho... c/Pe=F1a Primera 11-13 esc dcha 6B 37002 Salamanca Espa=F1a Spain -------------------------------------------------- telefono casa 923 27 10 82 movil 650 52 54 58 -------------------------------------------------- To call from the US dial 9:00 am Pacific US =3D home 011 34 923 271 082 12:00 noon Eastern US =3D cell 011 34 650 525 458 6:00 pm Spain -------------------------------------------------- |
From: Egon W. <eg...@sc...> - 2002-10-29 08:23:45
|
On Tuesday 29 October 2002 08:57, Miguel Howard wrote: > > I've been testing the samples/ files with the CVS version... then I > > realized that I could live with the problem in the next release, *if* > > loading a new file would reset the screen coordinates... now the become > > zero at a yet unknown event, and then stay zero... if they would be > > reset to a non-zero > > I am sorry, I do not understand what you mean by "the screen coordinates > become zero". All atoms are drawn in the upper left corner of the Jmol viewing window... Isn't that screencoordinates (0,0)? Or is lower left (0,0)? Egon |
From: mth <mt...@mt...> - 2002-10-29 09:06:03
|
> All atoms are drawn in the upper left corner of the Jmol viewing > window... Isn't that screencoordinates (0,0)? Or is lower left (0,0)? yes, upper left is 0,0 Now I have a picture of what you are seeing ... but I don't now why it is happening. I have been using the Mac for about 1/2 hour and have not been able to reproduce the bug. Therefore, I think the right thing to do is follow your suggestion of backing out the changes so that I don't impact release 5. I'll wait a few minutes to see if I hear back from you. Otherwise, I'll roll back the changes by retrieving the previous versions and checking them in. Miguel -------------------------------------------------- Miguel Howard mi...@ho... c/Pe=F1a Primera 11-13 esc dcha 6B 37002 Salamanca Espa=F1a Spain -------------------------------------------------- telefono casa 923 27 10 82 movil 650 52 54 58 -------------------------------------------------- To call from the US dial 9:00 am Pacific US =3D home 011 34 923 271 082 12:00 noon Eastern US =3D cell 011 34 650 525 458 6:00 pm Spain -------------------------------------------------- |
From: Egon W. <eg...@sc...> - 2002-10-29 09:44:56
|
On Tuesday 29 October 2002 10:05, mth wrote: > > All atoms are drawn in the upper left corner of the Jmol viewing > > window... Isn't that screencoordinates (0,0)? Or is lower left (0,0)? > > yes, upper left is 0,0 > Now I have a picture of what you are seeing ... but I don't now why it is > happening. Neither do I. Like Fabian found out, it does happen for all molecules, when you rotate to long... (> 10 secs?)... guess this is what one would call a race bug... I guess that at certain moments things are calculated that cannot be calculated at that specific moment yet... > I have been using the Mac for about 1/2 hour and have not been able to > reproduce the bug. > > Therefore, I think the right thing to do is follow your suggestion of > backing out the changes so that I don't impact release 5. > > I'll wait a few minutes to see if I hear back from you. Otherwise, I'll > roll back the changes by retrieving the previous versions and checking > them in. Ok, roll back the changes... Egon |
From: mth <mt...@mt...> - 2002-10-29 10:09:23
|
> > Ok, roll back the changes... > Done. Let me know when you have branched. I will then reintroduce more slowly with smaller steps, allowing you to verify after each check-in. mth |
From: Fabian D. <fab...@wa...> - 2002-10-29 16:54:17
|
On Tue, 2002-10-29 at 11:09, mth wrote: I've just done a test on the b5 branch. I still get the bug. > > > > Ok, roll back the changes... > > > Done. >=20 > Let me know when you have branched. I will then reintroduce more slowly > with smaller steps, allowing you to verify after each check-in. >=20 > mth >=20 >=20 >=20 >=20 >=20 >=20 > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Jmol-developers mailing list > Jmo...@li... > https://lists.sourceforge.net/lists/listinfo/jmol-developers >=20 --=20 ********** Fabian Dortu Phone : 32-475-599268 e-mail : Fab...@wa... ***********************************************=20 |
From: mth <mt...@mt...> - 2002-10-29 21:11:31
|
> > I've just done a test on the b5 branch. I still get the bug. > Fabian, I am quite confident that I backed out all the code that I checked in. mth |
From: Fabian D. <fab...@wa...> - 2002-10-30 07:52:44
|
On Tue, 2002-10-29 at 22:11, mth wrote: > > > > I've just done a test on the b5 branch. I still get the bug. > > > Fabian, >=20 > I am quite confident that I backed out all the code that I checked in. >=20 > mth Then it means that the bug *does* also occur in the previous implementation altough it is much more difficult to reproduce it: The best way I found to reproduce the bug is to first load samples/slab_7Si_3Vac_2x_relax_2x1.out, play a little and then load dna.xyz. The bug occurs immediately after I rotate. I think it may be a memory related problem. The machine I use has only 128Mb an run a lot of daemons. Fabian >=20 >=20 >=20 >=20 >=20 > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Jmol-developers mailing list > Jmo...@li... > https://lists.sourceforge.net/lists/listinfo/jmol-developers >=20 --=20 ********** Fabian Dortu Phone : 32-475-599268 e-mail : Fab...@wa... ***********************************************=20 |
From: mth <mt...@mt...> - 2002-10-30 08:00:09
|
>> > I've just done a test on the b5 branch. I still get the bug. >> I am quite confident that I backed out all the code that I checked in. > Then it means that the bug *does* also occur in the previous > implementation altough it is much more difficult to reproduce it: Fabian, You can easily confirm that the code you have does *not* include the changes by running the following command: grep screenX Atom.java Note that the X is in UPPER CASE. If grep finds nothing then you are running the previous version. mth |
From: Fabian D. <fab...@wa...> - 2002-10-30 08:08:13
|
I confirm, I run the previous version! On Wed, 2002-10-30 at 09:00, mth wrote: > >> > I've just done a test on the b5 branch. I still get the bug. >=20 > >> I am quite confident that I backed out all the code that I checked in. >=20 > > Then it means that the bug *does* also occur in the previous > > implementation altough it is much more difficult to reproduce it: >=20 > Fabian, >=20 > You can easily confirm that the code you have does *not* include the > changes by running the following command: > grep screenX Atom.java >=20 > Note that the X is in UPPER CASE. >=20 > If grep finds nothing then you are running the previous version. >=20 > mth >=20 >=20 >=20 >=20 > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Jmol-developers mailing list > Jmo...@li... > https://lists.sourceforge.net/lists/listinfo/jmol-developers >=20 --=20 ********** Fabian Dortu Phone : 32-475-599268 e-mail : Fab...@wa... ***********************************************=20 |
From: E.L. W. <eg...@sc...> - 2002-10-31 09:45:07
|
On Wednesday 30 October 2002 10:07, Fabian Dortu wrote: > I confirm, I run the previous version! Ok, that is nice to hear. Miguel, your code does apparently *not* introduce the bug, but *probably* due to the better performance, the bug become easier to detect. I would therefore suggest to include to full patch to the HEAD branch again, and try to find a way to solve the problem which is apparently already available in older versions as well... Fabian, Miguel, what do you think about that? Egon |
From: Fabian D. <fab...@wa...> - 2002-10-31 09:48:42
|
On Thu, 2002-10-31 at 10:45, E.L. Willighagen wrote: > On Wednesday 30 October 2002 10:07, Fabian Dortu wrote: > > I confirm, I run the previous version! >=20 > Ok, that is nice to hear. Miguel, your code does apparently *not* introdu= ce=20 > the bug, but *probably* due to the better performance, the bug become eas= ier=20 > to detect.=20 >=20 > I would therefore suggest to include to full patch to the HEAD branch aga= in,=20 > and try to find a way to solve the problem which is apparently already=20 > available in older versions as well... >=20 > Fabian, Miguel, what do you think about that? I agree.=20 >=20 > Egon >=20 --=20 ********** Fabian Dortu Phone : 32-475-599268 e-mail : Fab...@wa... ***********************************************=20 |
From: mth <mt...@mt...> - 2002-10-31 12:09:44
|
> Fabian, Miguel, what do you think about that? > I think that sounds fine. I have come up with a few ideas I would like you to try out on the slower machines. But we will have to talk about them next week. mth -------------------------------------------------- Miguel Howard mi...@ho... c/Pe=F1a Primera 11-13 esc dcha 6B 37002 Salamanca Espa=F1a Spain -------------------------------------------------- telefono casa 923 27 10 82 movil 650 52 54 58 -------------------------------------------------- To call from the US dial 9:00 am Pacific US =3D home 011 34 923 271 082 12:00 noon Eastern US =3D cell 011 34 650 525 458 6:00 pm Spain -------------------------------------------------- |