Re: Mathematica Graphics - speed bottleneck

*To*: mathgroup at smc.vnet.net*Subject*: [mg97711] Re: [mg97664] Mathematica Graphics - speed bottleneck*From*: John Fultz <jfultz at wolfram.com>*Date*: Thu, 19 Mar 2009 02:12:20 -0500 (EST)*Reply-to*: jfultz at wolfram.com

On Wed, 18 Mar 2009 04:54:02 -0500 (EST), robert prince-wright wrote: > > > Mathematica 7. has lured me back into using Mathematica at work and I am > wondering if it really has reached a point where it can be used to deploy > applications / solutions. I had some success with one small application > but found the graphics became a bottleneck which slowed to a grinding > halt when applied to a real problem. Key culprits were the vector field > plotting functions, and Graphics3D's ability to manipulate objects > comprising hundreds of tubes. It was fine for tens but not hundreds. This > led me to wonder if there are alternative approaches. I recall > LiveGraphics3D but it seems to have stopped at v5. Basically I want to > manipulate 3D graphics through use of DynamicModule, Sliders, etc. and > see the changes in realtime (as opposed to geological time!) > > Any thoughts? Not having seen your problem, I can't make any authoritative comment on what's causing your performance problems. If your examples are purely about manipulation of graphics primitives and spend lots of time in the graphics rendering pipelines, then there's probably not much that can be done without improvements to the front end or off-loading the rendering to another app. But you mention plotting vector fields as an example of something that's slow. This isn't just about the rendering pipelines. There's a large amount of computation that's going on here, too. Finding another rendering platform wouldn't help if, in your case, the time sink is in computing the primitives to be displayed rather than actually displaying them. So I wouldn't jump to any conclusions like "manipulating 3D graphics is slow" without first quantifying where the actual time is being spent. I will make a few quick remarks about graphics performance, though. In general, when dealing with large numbers of objects, things will be much more efficient if you use multi-primitives rather than many individual primitives. Primitives like Tube[], Point[], Line[], etc., all support forms where you can specify a collection of primitives by passing in a list of coordinate lists. E.g., randompoint := {RandomReal[], RandomReal[], RandomReal[]}; Graphics3D[Tube[Table[{randompoint, randompoint}, {50}]]] Secondly, 3D graphics with any transparency at all are always going to render far more slowly than 3D graphics without transparency. The overhead for sorting polygons is much higher when you take into account that you can actually see through some of them. Finally, Graphics3D supports the Method options "SpherePoints", "ConePoints", "CylinderPoints", and "TubePoints" which can specify the number of points used to render each kind of primitive in the entire scene. Providing a very small number can make a big performance difference with virtually no visual difference if the primitives are tiny or thin in your graphic. E.g., randompoint := {RandomReal[], RandomReal[], RandomReal[]}; Graphics3D[Tube[Table[{randompoint, randompoint}, {500}]], Method -> {"TubePoints" -> 6}] which rotates quite noticeably faster than if you omit the Method option. In the help viewer type =09tutorial/ThreeDimensionalGraphicsPrimitives to see documentation which discusses multi-primitives and the Method options. Sincerely, John Fultz jfultz at wolfram.com User Interface Group Wolfram Research, Inc.