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.