Re: Re: Version 6 graphics can be painfully slow
- To: mathgroup at smc.vnet.net
- Subject: [mg84939] Re: [mg84874] Re: Version 6 graphics can be painfully slow
- From: John Fultz <jfultz at wolfram.com>
- Date: Sun, 20 Jan 2008 03:38:28 -0500 (EST)
- Reply-to: jfultz at wolfram.com
This theory is pretty far off from what actually happens. In version 6, the
kernel has absolutely no involvement whatsoever in generating the rendered
image. 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.
On Thu, 17 Jan 2008 06:59:59 -0500 (EST), Nasser Abbasi wrote:
>
>
> ref (me)
>
> "Nasser Abbasi" <nma at 12000.org> wrote in message news:...
>
> ...
>
>> May be the FE tells the kernel to convert the Graphics to image format
>> and
>> the Kernel sends the image back to FE to display it, and so it could be
>> the kernel at fault also. Do not know details of the protocol.
>>
>
> fyi, I just watched the Mathematica kernel during the Show[] command
>
> In[3]:= t0 = TimeUsed[];
> Show[p]
> TimeUsed[] - t0
>
> And the Kernel DOES get 100% CPU busy during all the time. So FE must be
> sending the Graphics to the Kernel, and the Kernel converts to an image
> format and send the image back to FE for display.
>
> When I tried Graphics version 5, it indeed went very fast, the Kernel
> still
> did some CPU, but the whole thing went very fast.
>
> So, the problem seem in converting the Graphics to image format inside the
> kernel for the FE to display it. They must have changed the algorithm or
> something as such.
>
>
>>> I really hope that these problems will be fixed in 6.1, but until
>>> then,
>>> does anyone have a suggestion for speeding this up?
>>>
>>> (At the moment I temporarily switch back to << Version5`Graphics`)
>>>
>>> Szabolcs
>>>
>>
>> Nasser