MathGroup Archive 2009

[Date Index] [Thread Index] [Author Index]

Search the Archive

Re: Mathematica Graphics - speed bottleneck

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

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
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
to see documentation which discusses multi-primitives and the Method options.

John Fultz
jfultz at
User Interface Group
Wolfram Research, Inc.

  • Prev by Date: Re: Superscripts in post-processed plot labels
  • Next by Date: Re: Multivariate normal distribution
  • Previous by thread: Re: Mathematica Graphics - speed bottleneck
  • Next by thread: Re: Re: Mathematica Graphics - speed bottleneck