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.com<mailto: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.com<mailto:racket-users+unsubscr...@googlegroups.com>. For more options, visit https://groups.google.com/d/optout<https://urldefense.proofpoint.com/v1/url?u=https://groups.google.com/d/optout&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=Kjg6LltY9QjkipKooaVldA%3D%3D%0A&m=K7ydo0ZPjv7m8zxvDGYN7qMNIVTK9hTRK44h6w1AzV4%3D%0A&s=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.