The square the saturation / value field fills, centered in its node.

A headless context for tests: 16px monospace metrics, the measure cache on, text kept out of the vertex buffer, and the default theme.

Configure a context's theme. Goes through setTheme so a theme swapped between frames invalidates the caches keyed on it, drawing-op caches included, instead of leaving widgets painting the previous theme.

Explicit damage invalidation request queued during frame evaluation.

Move a scroller to an offset along its main axis. Cancels a glide in flight: whoever sets an offset outright owns it.

Whether the frame loop has to keep drawing: an animation is running, or a scroller is still gliding onto its target.

GPU texture id shared by every packed image so draw cmds batch.

Pixel box for a DrawText using host advances. diagrams text has no envelope, so plot sizing uses this instead of fontSizeL.

The Eff monad provides the implementation of a computation that performs an arbitrary set of effects. In Eff es a, es is a type-level list that contains all the effects that the computation may perform. For example, a computation that produces an Integer by consuming a String from the global environment and acting upon a single mutable value of type Bool would have the following type:

(Reader String :> es, State Bool :> es) => Eff es Integer

Abstracting over the list of effects with (:>):

• Allows the computation to be used in functions that may perform other effects.
• Allows the effects to be handled in any order.

Run an Eff computation with side effects.

For running pure computations see runPureEff.

Run arbitrary IO computations via MonadIO or MonadUnliftIO.

Note: it is not recommended to use this effect in application code as it is too liberal. Ideally, this is only used in handlers of more fine-grained effects.

A constraint that requires that a particular effect e is a member of the type-level list es. This is used to parameterize an Eff computation over an arbitrary list of effects, so long as e is somewhere in the list.

For example, a computation that only needs access to a mutable value of type Integer would have the following type:

State Integer :> es => Eff es ()

A Compact contains fully evaluated, pure, immutable data.

Compact serves two purposes:

• Data stored in a Compact has no garbage collection overhead. The garbage collector considers the whole Compact to be alive if there is a reference to any object within it.
• A Compact can be serialized, stored, and deserialized again. The serialized data can only be deserialized by the exact binary that created it, but it can be stored indefinitely before deserialization.

Compacts are self-contained, so compacting data involves copying it; if you have data that lives in two Compacts, each will have a separate copy of the data.

The cost of compaction is fully evaluating the data + copying it. However, because compact does not stop-the-world, retaining internal sharing during the compaction process is very costly. The user can choose whether to compact or compactWithSharing.

When you have a Compact a, you can get a pointer to the actual object in the region using getCompact. The Compact type serves as handle on the region itself; you can use this handle to add data to a specific Compact with compactAdd or compactAddWithSharing (giving you a new handle which corresponds to the same compact region, but points to the newly added object in the region). At the moment, due to technical reasons, it's not possible to get the Compact a if you only have an a, so make sure you hold on to the handle as necessary.

Data in a compact doesn't ever move, so compacting data is also a way to pin arbitrary data structures in memory.

There are some limitations on what can be compacted:

• Functions. Compaction only applies to data.
• Pinned ByteArray# objects cannot be compacted. This is for a good reason: the memory is pinned so that it can be referenced by address (the address might be stored in a C data structure, for example), so we can't make a copy of it to store in the Compact.
• Objects with mutable pointer fields (e.g. IORef, MutableArray) also cannot be compacted, because subsequent mutation would destroy the property that a compact is self-contained.

If compaction encounters any of the above, a CompactionFailed exception will be thrown by the compaction operation.

The character index whose caret is nearest x: from the shaped carets when the text was prepared by a shaping host, which handles clusters and right-to-left runs, and otherwise from the same advances and kerning as pushText, so the caret lands where the glyph to its left was drawn.

Where the caret before character i of txt sits: a shaped caret when the snapshot was prepared for txt, else the width of the characters before it.

The horizontal extents covering characters lo to hi: one span for left-to-right text, and a span per direction run where a selection crosses right-to-left text.