#258 Performance issue

HEAD
closed
Miguel
None
5
2004-11-20
2004-08-26
Nicolas
No

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)

Discussion

  • Nicolas

    Nicolas - 2004-08-26

    10.000 atoms

     
  • Miguel

    Miguel - 2004-08-26

    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 :-)

     
  • Miguel

    Miguel - 2004-08-26
    • assigned_to: nobody --> migueljmol
     
  • Nicolas

    Nicolas - 2004-08-26

    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

     
  • Miguel

    Miguel - 2004-08-26

    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

     
  • Nicolas

    Nicolas - 2004-08-26

    Logged In: YES
    user_id=1096197

    To answer you Q : I tried to promote Jmol among people
    participating in the Folding@Home 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.

     
  • Nicolas

    Nicolas - 2004-09-12

    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.

     
  • Nicolas

    Nicolas - 2004-09-12

    Sphere3D.renderBigClipped() modified

     
  • Miguel

    Miguel - 2004-09-13

    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.

     
  • Nicolas

    Nicolas - 2004-09-15

    Shade3D.calcDitheredNoisyIntensity() modified

     
  • Nicolas

    Nicolas - 2004-09-15

    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.

     
  • Miguel

    Miguel - 2004-09-16

    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.

     
  • Nicolas

    Nicolas - 2004-11-20
    • status: open --> closed
     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks