▼ |  | Images

1 | Icons
2 | Logos
3 | Embedding Bitmaps in Compiled Files
4 | Floating-Point Bitmaps

On this page:

compiled-bitmap
compiled-bitmap-list

Version: 5.3.1
top ← prev up next →

### 3`` Embedding Bitmaps in Compiled Files

Neil Toronto <neil.toronto@gmail.com>

( require images/compile-time )

Producing computed bitmaps can take time. To reduce the startup time of programs that use computed bitmaps, use the macros exported by images/compile-time to compile them: to embed the computed bitmaps in fully expanded, compiled modules.

This is a form of constant folding, or equivalently a form of safe “3D” values. The macros defined here compute bitmaps at expansion time, and expand to the bitmap’s bytes and a simple wrapper that converts bytes to a bitmap%. Thus, fully expanded, compiled modules contain (more or less) literal bitmap values, which do not need to be computed again when the module is required by another.

The literal bitmap values are encoded in PNG or JPEG format, so they are compressed in the compiled module.

To get the most from compiled bitmaps during development, it is best to put them in files that are changed infrequently. For example, for games, we suggest having a separate module called something like images.rkt or resources.rkt that provides all the game’s images.

> > syntax

> > ( compiled-bitmap expr [quality])

> > | expr |  | : |  | ( is-a?/c bitmap% )

> > | quality |  | : |  | ( integer-in 0 100)

Evaluates expr at expansion time, which must return a bitmap%, and returns to the bitmap at run time. Keep in mind that expr has access only to expansion-time values, not run-time values.

If quality is 100, the bitmap is stored as a PNG. If quality is between 0 and 99 inclusive, it is stored as a JPEG with quality quality. (See save-file.) If the bitmap has an alpha channel, its alpha channel is stored as a separate JPEG. The default value is 100.

Generally, to use this macro, wrap a bitmap%-producing expression with it and move any identifiers it depends on into the expansion phase. For example, suppose we are computing a large PLT logo at run time:

> #lang racket

> ( require images/logos)
> ( define the-logo ( plt-logo #:height 384))

Running this takes several seconds. It produces

> > the-logo

To move the cost to expansion time, we change the program to

> #lang racket
> ( require images/compile-time
> ( for-syntax images/logos))
> ( define the-logo ( compiled-bitmap ( plt-logo #:height 384)))

The logo is unchanged, but now expanding (and thus compiling) the program takes several seconds, and running it takes a few milliseconds. Note that images/logos is now required for-syntax, so that the expansion-phase expression ( plt-logo #:height 384) has access to the identifier plt-logo.

> > syntax

> > ( compiled-bitmap-list expr [quality])

> > | expr |  | : |  | ( listof ( is-a?/c bitmap% ))

> > | quality |  | : |  | ( integer-in 0 100)

Like compiled-bitmap, but it expects expr to return a list of bitmap%s, and it returns the list at run time. The quality argument works as in compiled-bitmap, but is applied to all the images in the list.

Use this for animations. For example,

> #lang racket

> ( require images/compile-time
> ( for-syntax images/icons/stickman))
> ( begin-for-syntax
> ( define num-stickman-frames 12))
> ( define running-stickman-frames
> ( compiled-bitmap-list
> ( for/list ([t ( in-range 0 1 ( / 1 num-stickman-frames))])
> (running-stickman-icon t #:height 32
> #:body-color "red"
> #:arm-color "white"
> #:head-color "red"))
> 50))

This computes

> > running-stickman-frames
> (list )

at expansion time.
top ← prev up next →