MathGroup Archive 2008

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

Search the Archive

Re: Re: Version 6 graphics can be painfully slow

  • To: mathgroup at smc.vnet.net
  • Subject: [mg84896] Re: [mg84874] Re: Version 6 graphics can be painfully slow
  • From: "Nasser Abbasi" <nma at 12000.org>
  • Date: Fri, 18 Jan 2008 05:49:22 -0500 (EST)
  • References: <200811712815.794775@jfultz2winlap>
  • Reply-to: "Nasser Abbasi" <nma at 12000.org>

>From: "John Fultz" <jfultz at wolfram.com>


>This theory is pretty far off from what actually happens.

Ok, but it is a theory, but it is based on solid observations :).

>  In version 6, the kernel has absolutely no involvement whatsoever in 
> generating the rendered
>image.

That is what I first said actually, it makes sense, but when I saw the 
kernel going 100% CPU during the whole time the Show command was running, 
and the FE was not using any CPU time, I thought that is what is happening. 
(i.e. kernel is converting graphics to image)

I made a movie showing this on my PC (duel core intel CPU) in case someone 
is interested, here it is (it is 16 MB AVI movie), where I type in the Show 
command and have the windows CPU task manager up showing the CPU of the Math 
kernel and the FE.

If you go to link below and click on the test3.avi file

http://12000.org/tmp/mathematica_kernel/

Thanks John for explaining in more details what is going on below and what 
could be causing the CPU time for the kernel, very useful information. May 
be more of these things can be written down in tutorials and added to 
documentation center, under may be something like 'Mathematica design 
internal' section for us users to read.

Nasser

"The steps taken in displaying a graphic in version 6 are very much like
those used in displaying non-graphical output.  It works as follows:

1) The expression is evaluated, and ultimately produces something with head
Graphics[] or Graphics3D[].

2) The resulting expression is passed through MakeBoxes.  MakeBoxes has a 
set of
rules which turns the graphics expression into the box language which the 
front
end uses to represent graphics.  E.g.,

In[9]:= MakeBoxes[Graphics[{Point[{0, 0}]}], StandardForm]

Out[9]= GraphicsBox[{PointBox[{0, 0}]}]

Internally, we call this the "typeset" expression.  It may be a little weird
thinking of graphics as being "typeset", but it's fundamentally the same
operation which happens for typesetting (which has worked this way for 11
years), so I'll use the term.

3) The resulting typeset expression is sent via MathLink to the front end.

4) The front end parses the typeset expression and creates internal objects
which generally have a one-to-one correspondence to the typeset expression.

5) The front end renders the internal objects.


In version 6, the front end, and only the front end can render graphics 
(unless
you use the legacy PostScript scheme via <<Version5`Graphics`, in which the
kernel does the hard job of rendering the graphic to a simple subset of
PostScript, and the FE has the considerably easier job of merely rendering 
the
PostScript to the screen).

There are three big opportunities for slowness to happen here if you don't 
use
multi-points (i.e. a single Point with multiple coordinates):

* MakeBoxes has more work to do with a large table of Point[]'s than with a
Point[] of a large number of coordinates.
* The data transmission over MathLink is significantly more time-consuming 
when
you're sending a large number of PointBox[] objects than when you're sending 
a
single PointBox[] with a large number of coordinates.
* The front end has to construct a large number of internal PointBox[] 
objects
separately rather than a single PointBox[] object with many coordinates.

The first two can contribute directly to the kernel CPU usage you're seeing. 
I
don't know exactly in what proportion these three contribute to the slowness
(exercise for the reader if you're really that interested), but each does 
make a
significant contribution.

Sincerely,

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



  • Prev by Date: Re: Mouse operation, slider, dynamics, plot combination
  • Next by Date: Re: Strange interaction between local symbols of a proc inside the
  • Previous by thread: Re: Version 6 graphics can be painfully slow
  • Next by thread: Re: Version 6 graphics can be painfully slow