Services & Resources / Wolfram Forums / MathGroup Archive
-----

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: [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




  • Prev by Date: Re: Mathematica commenting of code using (* *) can't be nested
  • Next by Date: Re: Don't understand behavior of ClearAttributes[Plus,
  • Previous by thread: Re: Version 6 graphics can be painfully slow
  • Next by thread: Don't understand behavior of ClearAttributes[Plus,Orderless]