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

Re: Timing graphics in the real world

• To: mathgroup at smc.vnet.net
• Subject: [mg123007] Re: Timing graphics in the real world
• From: "Oleksandr Rasputinov" <oleksandr_rasputinov at hmamail.com>
• Date: Sun, 20 Nov 2011 05:36:51 -0500 (EST)
• Delivered-to: l-mathgroup@mail-archive0.wolfram.com
• References: <ja856s$iiq$1@smc.vnet.net>

On Sat, 19 Nov 2011 11:50:52 -0000, Ralph Dratman  
<ralph.dratman at gmail.com> wrote:

> I am trying to find out why a piece of 3D graphics code takes a long
> time when scaled up to a lot of little objects.
>
> [...]
>
> Drawing is taking about 140 times longer than
> Mathematica says!
>
> [...]
>
> Ralph Dratman
>

The reason for this is that Timing and AbsoluteTiming reflect only the  
time taken for the kernel to build the Graphics expression. The actual  
rendering of the graphic is done by the front end, and although this takes  
most of the total time it is not reflected in the reported timings.  
Certainly the rendering speed for complicated Graphics3D expressions is  
not particularly impressive, and in the past there have been faster  
alternative renderers capable of interpreting the kernel's Graphics  
output, such as JavaView (http://www.javaview.de/mathematica/index.html;  
unfortunately limited to pre-version 6 Graphics expressions), but I don't  
know of any such that will understand the output from more recent  
Mathematica kernels. What, if anything, will speed up the front end's  
rendering, I do not know--this is heavily dependent on implementation  
details that are likely known only to WRI.