Bugs item #1016913, was opened at 2004-08-26 16:29 Message generated for change (Comment added) made by migueljmol You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=379133&aid=1016913&group_id=23629
Category: None Group: HEAD Status: Open Resolution: None Priority: 5 Submitted By: Nico (nicove) Assigned to: Miguel (migueljmol) Summary: Performance issue Initial Comment: With the big file attached, I have performance problems : - visualisation with 100% van der waals, - zoom in closely, - from then on, if I click and move the mouse JMol is stuck during redraw (several redraws are done one after an other, each one taking several seconds) ---------------------------------------------------------------------- >Comment By: Miguel (migueljmol) Date: 2004-09-16 05:24 Message: Logged In: YES user_id=1050060 None of those routines were optimized for performance, so there are probably other opportunities to find things. Take a look at that code and see if you see anything else. Then I will check in the changes. Separately, here is another thought. When you are zoomed in closely most of the atoms are not visible on the screen. Take a look and see whether or not the code in the atom rendering is eliminating all the off- screen atoms early. That is, if an atom is completely off-screen then it should never reach the 'renderBigSphere' stage. ---------------------------------------------------------------------- Comment By: Nico (nicove) Date: 2004-09-15 22:35 Message: Logged In: YES user_id=1096197 It's a idea, but the display may look less good. Before trying this, I prefer trying to optimize other things that don't change the display. I have found one : I have modified Shade3D.calcDitheredNoisyIntensity() and it seems to go 25% faster. I don't think it makes a noticeable difference on the overall performance, but it's a first step. The solution I found: add an param containing the radius (sqrt (x*x+y*y+z*z)) so the method doesn't have to compute it. The radius is already available when this method is called by Sphere3D. ---------------------------------------------------------------------- Comment By: Miguel (migueljmol) Date: 2004-09-13 19:55 Message: Logged In: YES user_id=1050060 Very good. Thanks for taking the time to do this. I have checked-in this code. If you *really* want it to go fast, we could consider the following approach: When spheres get big, just render them with 'fat' pixels. That is, rather than using 1 pixel, use 2x2 (or 3x3) pixels. The advantage would be that we could use the precomputed sphere surfaces/shapes that are used for smaller spheres. This would mean that rendering large spheres would be just as fast as rendering small spheres. The disadvantage is that the 'staircase' effect along the edges would be worse. ---------------------------------------------------------------------- Comment By: Nico (nicove) Date: 2004-09-12 09:37 Message: Logged In: YES user_id=1096197 I made an optimization for the drawing for big clipped spheres (method Sphere3D.renderBigClipped() attached). I use the same algo as big unclipped spheres with some tests in addition. To check the performance gain, I modified the Sphere3D.render() method to call the previous methods 1000 times instead of one. The original algo of renderBigClipped() was ~7 times slower than renderBigUnclipped(). With the modification, renderBigClipped() is at minimum as fast as renderBigUnclipped (), even several times faster when the sphere is clipped a lot. ---------------------------------------------------------------------- Comment By: Nico (nicove) Date: 2004-08-26 21:08 Message: Logged In: YES user_id=1096197 To answer you Q : I tried to promote Jmol among people participating in the [EMAIL PROTECTED] project (the Tinker format I asked about). One of them told me, it found it really slow with a lot of atoms : at first I didn't understand why so I tried different combinations and got those performance issues when zooming alot. ---------------------------------------------------------------------- Comment By: Miguel (migueljmol) Date: 2004-08-26 20:53 Message: Logged In: YES user_id=1050060 Jmol does not do any queuing of mouse events ... that is all handled by the underlying system. And the the underlying environment (windowing system + java implementation) *should* collapse multiple repaint events into a single event. If that is not happening then it is a problem. I cannot think of any way that Jmol could collapse these events. I will keep thinking about it, but I am not optimistic that we can solve the problem. Q: Why do you want to zoom in so close? Miguel ---------------------------------------------------------------------- Comment By: Nico (nicove) Date: 2004-08-26 20:43 Message: Logged In: YES user_id=1096197 Ok, I can understand that the drawing can be very slow in some conditions (more 50 or 100 times slower in my case ;) ). But, there is an other issue : it seems that the mouse movements are stacked, so if you move the mouse for several seconds and then release it, Jmol redraws several times (about 5 to 10 seconds for each redraw) : redraws can last several minutes in total. Would it be possible to redraw only the last position ? It would accelerate a lot. If not, don't worry about it. Thanks for the answer ---------------------------------------------------------------------- Comment By: Miguel (migueljmol) Date: 2004-08-26 19:45 Message: Logged In: YES user_id=1050060 When you zoom in closely Jmol always has performance problems. If the diameter of a sphere is >128 pixels then the time required to render the sphere goes up by a *lot* ... 25 times slower? This will be very low priority for me to fix ... don't zoom in so close :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=379133&aid=1016913&group_id=23629 ------------------------------------------------------- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php _______________________________________________ Jmol-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jmol-developers
