That was the first thing I tried, and it got substantially slower. Of the
three ways to create large bitmaps, one of them was fast on MacOS, and all of
them are slow on Windows. Using a 4096x768 bitmap is clearly not going down a
fully hardware accelerated path.
From: racket-users@googlegroups.com [mailto:racket-users@googlegroups.com] On
Behalf Of Stephen Bloch
Sent: Tuesday, August 25, 2015 6:10 AM
To: racket-users@googlegroups.com
Subject: [racket-users] 2htdp/universe performance
John Carmack writes:
The performance problems were related to the larger scrolling worlds. The H2DP
versions got slower the more clouds were in the maps.
If the background is basically static but scrolling, you might get a
substantial performance improvement by
(define background (freeze big-expression-that-builds-the-background))
and using that variable henceforth. (The “freeze” function renders an image
expression to a bitmap once and for all, trading memory for time.) If not the
WHOLE background is basically static, but you have a lot of repeated elements
(say, a bunch of identical clouds), you can
(define cloud (freeze big-expression-that-builds-a-cloud))
and use that variable instead of the big expression henceforth. There’s no
harm in doing both, e.g.
(define background (freeze … cloud … cloud … cloud … ))
although this won’t buy you any additional performance.
The idea that you functionally compose images like this:
...
Which draws image1 on top of image2 on top of image 3, which is backwards from
the painters order that would draw image 3, then image 2, then image 1.
This imperative, side-effect-ing code is a little less clear to a beginner with
the OOP and DC concepts, but It better represents what actually happens, and it
is much easier to modify the code without worrying about the nesting.
It’s not clear to me that the imperative style “better represents what actually
happens,” nor that this matters.
However, there is a big win associated with the functional approach: it forces
model-view separation from the beginning. Model-view separation is how almost
all GUI programs are written, and failures to follow it cause a lot of the
display bugs in GUI programs. Students who learn an imperative-first approach
to GUI invariably end up writing display handlers that modify the model, or
mouse handlers that draw to the display, causing the aforementioned display
bugs.
Stephen Bloch
sbloch1...@gmail.commailto:sbloch1...@gmail.com
--
You received this message because you are subscribed to the Google Groups
Racket Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to
racket-users+unsubscr...@googlegroups.commailto:racket-users+unsubscr...@googlegroups.com.
For more options, visit
https://groups.google.com/d/optouthttps://urldefense.proofpoint.com/v1/url?u=https://groups.google.com/d/optoutk=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0Ar=Kjg6LltY9QjkipKooaVldA%3D%3D%0Am=K7ydo0ZPjv7m8zxvDGYN7qMNIVTK9hTRK44h6w1AzV4%3D%0As=1102dd791cbf03a04b142170144b798ed07a688b2e0e8dbb393ead3d538b74d6.
--
You received this message because you are subscribed to the Google Groups
Racket Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
