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.