TeenyApps/Articles/Presentation rehearsal

Mac presentation rehearsal checklist for colors and CPU

A rehearsal should catch more than whether the slides advance. Check what the audience will actually see, then make sure the Mac is not still busy from the setup work.

Published July 5, 2026 8 min read By John Sciacchitano

The short answer: rehearse with the real deck, browser tab, demo app, display, and meeting stack. Check the colors that carry meaning, including slide text, links, warnings, charts, and code. Then watch CPU, memory, and fan trend for one minute before the audience joins. If the Mac is still under unexplained load, open Activity Monitor before presenting.

This is narrower than a full Mac presentation display and audio checklist. That guide covers room setup, display mode, and sound output. This one is the final rehearsal pass for two things that are easy to miss: unreadable rendered colors and a Mac that is still working hard in the background.

Disclosure: I build TeenyApps, including TeenyColor for local screen color sampling and TeenyStat for CPU, memory, and fan speed in the menu bar. My bias is toward small native Mac utilities. The baseline is still the presentation app, macOS Displays, macOS Sound, and Activity Monitor when you need process names.

Rehearsal decision table

Risk Check first Decision rule
Slide text looks fine on your Mac but weak on the room display Open the rendered slide at real size and sample foreground/background colors. Fix the slide when the important text cannot meet the contrast threshold for its size.
Chart colors or status colors lose meaning Check colors that signal success, warning, failure, links, or selected state. Add labels or change colors when color alone carries the point.
The Mac feels sluggish before the call Watch CPU, memory, and fan trend after the deck, demo, browser, and meeting app are open. Ignore short launch spikes. Investigate sustained or unexplained load.
You need to know which app is causing load Open Activity Monitor and sort or search for the process. A menu bar signal starts the question. Activity Monitor names the process.
Something breaks five minutes before presenting Use one backup file, one fallback display mode, and one note with the final changes. If the fallback is hard to find, it is not a fallback.

01Rehearse the rendered presentation, not the idea

Do not judge a presentation from the outline, the design file, or a tiny editor preview. Open the exact thing the audience will see: Keynote slideshow, PowerPoint presentation, browser demo, screen-share view, PDF deck, video, or prototype.

Use the real display setup. If you will present on an external monitor, projector, conference-room display, or shared screen, rehearse there. The issue you need to catch is usually contextual: a faint gray caption, a low-contrast code block, a warning color that looks decorative, or a chart series that collapses when the display is dim.

Write down the visible failure, not just the slide number. "Slide 12, code comments too gray on the room display" is useful. "Slide 12 looks bad" is not.

02Check colors that carry meaning

Most slide colors do not need a measurement. The ones that carry meaning do: body text, small captions, code samples, links, button states, error or warning labels, and chart colors where the color explains the point.

TeenyColor fits this local check because it samples visible screen pixels through macOS, converts values to sRGB, copies in formats such as Hex, RGB, HSL, SwiftUI, UIColor, and CSS rgba, stores local color history, supports pinned colors, and shows WCAG contrast labels against white and black. Its Swift source uses NSColorSampler for picking and includes a WCAG 2.1 contrast-ratio helper.

For the narrower slide workflow, use the TeenyColor guide to checking presentation slide contrast on Mac.

Use it narrowly. Sample the rendered foreground and background, record the ratio when text readability is the question, then fix the slide or add labels. For normal-size text, WCAG's contrast guidance uses 4.5:1 as the minimum. Large text has a 3:1 threshold. A rehearsal does not need to become a full accessibility audit, but it should catch a slide that people cannot read.

03Watch CPU and memory after the stack is open

A presentation stack can be heavier than it looks. A browser demo may keep compiling, a video may preload, a PDF may index, a screen-share app may spin up helpers, and a build or export from earlier work may still be running. If you rehearse during that load, you may blame the deck when the Mac is simply busy.

TeenyStat is useful as a first read because it keeps CPU, memory, and fan speed visible in the menu bar or popover. The homepage describes selectable menu bar metrics, thresholds, sparklines, alerts, and per-core CPU detail. The local Swift source reads CPU through host_processor_info, memory through host_statistics64, and fan speed through SMC on Macs with fans.

For a deeper system-load pass, use the TeenyStat guide to checking CPU and memory when a Mac presentation lags.

Open the deck, meeting app, demo app, browser tabs, and notes. Wait for the obvious launch spike. Then watch one minute. CPU that settles is normal. CPU that stays high for no obvious reason, memory that keeps climbing, or fan speed that ramps after the setup work ends deserves a closer look before people join.

04Use Activity Monitor when the signal needs names

A menu bar stat tells you the Mac is under load. It does not tell you whether the culprit is the browser, meeting app, presentation app, a helper process, indexing, or something you forgot to close. Apple's Activity Monitor is the right tool when you need process names, columns, search, grouping, CPU activity, memory usage, or the Stop button.

Use a simple boundary: keep TeenyStat or another menu bar monitor for the first signal, then open Activity Monitor when the load is sustained, unexplained, risky, or tied to a visible slowdown. Sort by CPU when the processor is busy. Use the Memory pane when the Mac feels slow and memory pressure is the likely story.

If you are minutes from presenting, be conservative. Quit normal apps first. Force Quit only when you understand what you are stopping and losing unsaved work is acceptable.

05Save one rehearsal note

The best rehearsal note is short enough to use under pressure. Save the deck name, version, room or call setup, display mode, final color fixes, performance state, backup file, and fallback plan.

A useful note can be plain:

  1. Deck or demo version.
  2. Display setup: mirrored, extended, projector, external monitor, or screen share.
  3. Slides fixed for contrast, chart labels, or code readability.
  4. CPU, memory, and fan state after the stack was open for one minute.
  5. Apps closed before presenting.
  6. Backup file and fallback display mode.

If a problem repeats across rehearsals, turn it into a template change. If it is a one-off room issue, keep the note with that room or event and move on.

Ten-minute Mac presentation rehearsal

  1. Open the exact deck, demo, PDF, browser tab, or meeting stack.
  2. Use the same display mode and viewing distance you will use live.
  3. Read the smallest slide text, chart labels, code samples, and captions.
  4. Sample foreground/background colors when readability is uncertain.
  5. Add labels when a chart or status color carries meaning by itself.
  6. Open the meeting app, notes, demo app, browser, and any media source.
  7. Watch CPU, memory, and fan trend for one minute.
  8. Open Activity Monitor if the load stays high or has no obvious source.
  9. Close background work that does not belong in the presentation.
  10. Save one rehearsal note with fixes, backup file, and fallback path.

Sources checked

FAQ

What should I check during a Mac presentation rehearsal?

Open the real presentation stack, check slide readability and contrast, confirm the display and audio path, watch CPU and memory for a minute, then save a short note with the backup file and any fixes.

Why check CPU before presenting from a Mac?

A deck, browser demo, video, screen share, or export can leave the Mac busy before the audience joins. A short CPU and memory check tells you whether to wait, close background work, or open Activity Monitor.

Should I sample slide colors from the design file or the screen?

For rehearsal evidence, sample the rendered slide or projected screen because that is what the audience sees. Use the design file only when you need the source color token.

Related articles

Rehearse what people will actually see.

TeenyApps are small native Mac menu bar utilities for colors, system stats, display control, app audio, clipboard history, screenshots, mic mute, screen time, file staging, and local text tools.

Explore TeenyApps More articles