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."