[plt-scheme] 2htdp/image questions

Exactly.

And the only reason I went all the way to 3,000 rectangles was because I had
no other computations running in that example.  My student's actual game
gets choppy after about 50-100 shapes.

My student was able to compromise and create a very playable game.  But
after realizing that the bottleneck in his game was not our collision
detections but rather the actual rendering of the background, I decided to
look for workarounds.  The program would be able to handle a larger, busier
world if only I could flatten the constructed background programmatically.

That said, I agree that we've not been overly restricted by Universe's
limitations.  We've done a lot with the World, and I hope to have time to do
a networked project before the year ends.

-Paul


> -----Original Message-----
> From: robby.findler at gmail.com [mailto:robby.findler at gmail.com] On Behalf
> Of Robby Findler
> Sent: Thursday, April 22, 2010 12:52 PM
> To: Matthias Felleisen
> Cc: engineer at alum.mit.edu; plt-scheme at list.cs.brown.edu
> Subject: Re: [plt-scheme] 2htdp/image questions
> 
> I think that Paul was observing that a large bitmap'd image did not
> impose an undue penalty, but an image constructed out of 3,000 small
> overlaid images did. (But perhaps the sentiment of you messages still
> applies.)
> 
> Robby
> 
> On Thu, Apr 22, 2010 at 9:54 AM, Matthias Felleisen
> <matthias at ccs.neu.edu> wrote:
> >
> >
> >> ; INSERT HI-RES IMAGE HERE ********
> >> ;; I used a 1200x900 cut-n-paste of a digicam photo via MS Paint
> >> (define HI-RES {text "Insert large bitmap here" 20 "black"})
> >
> >
> > Yes, a 1200 x 900 photo will impose a heavy burden on the universe
> drawing
> > as implemented. We have played with tricks to do the rendering right and
> we
> > are okay with say 800 by 800, but barely. If in addition your tick
> handler
> > demands a lot of work, we're out of luck.
> >
> > Matthew and I have discussed an alternative semantics (what a tick means
> > isn't all that obvious) and I intend to implement it over the summer. I
> > doubt, however, that the result will cope with your images. Even if, I
> can
> > imagine that someone with a 30in monitor (I just got one) will use an
> even
> > larger image as background.
> >
> > To accommodate this world properly, I have considered a slightly
> different
> > API where the result of a render function can be the addition to an
> existing
> > background. I may implement this in addition to the above changes.
> >
> > ;; ---
> >
> > All in all, Universe is a relatively simplistic functional library for
> > teaching and is intended for simple, small animations. If you are using
> this
> > in a teaching context, please try to use modest images and backgrounds
> (400
> > x 400, 600 x 800 should be okay). I think students can still have fun
> with
> > these modest sizes. We just had a game design contest for our freshman
> > semester (trailer) and kids wrote fantastic, multi level games -- and
> they
> > were well-designed.
> >
> > Thanks -- Matthias
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > On Apr 22, 2010, at 10:39 AM, <engineer at alum.mit.edu> wrote:
> >
> >> Attached is an example that shows some poor performance.
> >>
> >> The animation has four ways to render the background:
> >> 1. Use a blank rectangle
> >> 2. Use place-image to create a complex image which is recreated from
> >> scratch
> >> each time render is called
> >> 3. Create an image like in #2 but store it as a constant before the
> >> animation starts.  Render then references this constant as the
> background
> >> scene for the animation each time.
> >> 4. Use a constant hi-res photo as the background.
> >>
> >> I found that #1 and #4 run okay, but #2 and #3 show choppy animation of
> >> the
> >> foreground.
> >>
> >> I pulled my hi-res photo out of the code to make the file more
> attachment
> >> friendly.
> >>
> >> Thanks,
> >> Paul
> >>
> >> Paul R. Ojanen
> >> Math/Physics/Computer Science Instructor
> >> Technology Director
> >> The Academy at King
> >> 5825 Old Jonesboro Rd
> >> Bristol, TN 37620
> >>
> >>> -----Original Message-----
> >>> From: plt-scheme-bounces at list.cs.brown.edu [mailto:plt-scheme-
> >>> bounces at list.cs.brown.edu] On Behalf Of Robby Findler
> >>> Sent: Thursday, April 22, 2010 8:28 AM
> >>> To: Noel Welsh
> >>> Cc: plt-scheme at list.cs.brown.edu
> >>> Subject: Re: [plt-scheme] 2htdp/image questions
> >>>
> >>>> On Wed, Apr 21, 2010 at 3:33 AM, Stephen Bloch <sbloch at adelphi.edu>
> >>>
> >>> wrote:
> >>>>>
> >>>>> But why do I (or my students) have to go through a feature-request
> >>>
> >>> process
> >>>>>
> >>>>> to get additional operations, rather than having an easy way to
> write
> >>>
> >>> them
> >>>>>
> >>>>> ourselves?
> >>>
> >>> One possible answer: you don't. Make a copy of the 2htdp/image and go
> >>> wild. Put it on planet if you think I'm so unresponsive that I won't
> >>> even accept patches.
> >>>
> >>> One possible other answer: asking for an easy way to add features to
> >>> library is in fact a feature. :)
> >>>
> >>> That said, I do plan to do more with 2htdp/image. I just don't expect
> >>> I'll have time for a few months. I welcome your experimentation in
> >>> that time; lots of the work is figuring out exactly what to do, often
> >>> that's easier than doing it, once the "what" is settled.
> >>>
> >>> As for a recent comment here, I don't think that we want to add a
> >>> "rasterize" or "make this be a bitmap" operation to 2htdp/image since
> >>> that brings in a performance model to teach to the students, at least
> >>> without exploring other alternatives. I have not had a chance to look
> >>> into the specific performance problem that was mentioned here earlier,
> >>> but but I would hope that there is a better solution than making the
> >>> students do extra work.
> >>>
> >>> Speaking of which, if someone has a badly performing program, please
> >>> do share it so I can investigate more effectively.
> >>>
> >>> Thanks,
> >>> Robby
> >>> _________________________________________________
> >>>  For list-related administrative tasks:
> >>>  http://list.cs.brown.edu/mailman/listinfo/plt-scheme
> >>
> >> <animation
> slowdown.ss>_________________________________________________
> >>  For list-related administrative tasks:
> >>  http://list.cs.brown.edu/mailman/listinfo/plt-scheme
> >
> >