[racket] fruit flies

I think the computation of which pixels are in the circles and which
aren't (and the shades of color around the edge) is what dominates.
Not the small amount of allocation that goes into representing the
objects (in this case, a data structure proportional to the size of
the number of circles). So I don't think that your analysis is of the
right things. At least that'd be my first guess. But as we all know,
performance is hard to predict and there could be unrelated things
that crop up in funny ways.

Robby

On Mon, Sep 12, 2011 at 9:41 PM, Shriram Krishnamurthi <sk at cs.brown.edu> wrote:
> Robby --
>
> I don't know enough about how the internal drawing routine of DrRacket
> works, so you could help clarify that.
>
> In 2htdp/universe, the act of "movement" is represented by
> reconstructing the entire scene.  Of course, there may be sharing:
>
> (define bg ... something complex ...)
>
> ;; at time 1
> (place-image I 50 50 bg)
>
> ;; at time 2
> (place-image I 70 70 bg)
>
> When this is finally rendered as a single image in the window, how
> much work is done?  Is it proportional to the size of the scene, or is
> it only proportional to the pixels that changed between the scene at
> time 1 and the scene at time 2?  Does the library perform a diff
> between the two scene graphs?
>
> In Whalesong's web-world, the act of "movement" is represented by a
> cursor finding the object and functionally updating its CSS.  After
> web-world does its tree-diff, it uses a *mutative update* to change
> the CSS attributes.  My understanding is that the browser DOM
> implementation then uses this information to update the screen as
> efficiently as possible (using Z depth to avoid unnecessary redraws,
> clipping, bitblit, etc).
>
> Thus, in web-world, the amount of work should be proportional to the
> number of affected pixels and *independent* of the number of
> unaffected ones.  Is this true of 2htdp/image/universe?
>
> Shriram
>