Merge branch 'main' into perf/slicing-optimizations

docs/HLSD/adaptive-infill.md

@@ -1,8 +1,8 @@
-# Adaptive TPMS infill — High Level Design
+# Adaptive infill — High Level Design
 
 ## Purpose and scope
 
-`tpms_adaptive` grades the sparse infill of the Gyroid, TPMS-D and TPMS-FK
+`adaptive_infill_mode` grades the sparse infill of the Gyroid, TPMS-D and TPMS-FK
 patterns inside the object: the cells grow continuously from the surface
 towards the center of the object. `distance_warp`, `smooth_blend` and
 `stepped_shells` follow the distance to the nearest surface, including the top
@@ -10,8 +10,8 @@ and bottom, like concentric shells; `lobes` follows the whole 3D shape towards
 the center of each lobe of the object; `normal_z`, `normal_y` and `normal_x`
 follow each section of the object normal to that axis, so the grading does not
 change along the axis, as suits a profile extruded along it.
-`sparse_infill_density` is the density at the surface, `tpms_interior_density`
-the density at the center, and `tpms_adaptive_gradient` picks how the density
+`sparse_infill_density` is the density at the surface, `adaptive_infill_interior_density`
+the density at the center, and `adaptive_infill_gradient` picks how the density
 goes from one to the other. Only internal sparse infill is graded; the Gyroid
 Z-buckling optimization does not apply to it.
 
@@ -22,9 +22,9 @@ split into shells or blended between densities.
 
 ## Radial field
 
-`TpmsRadialField` gives every point of an object the center of its lobe and a
+`AdaptiveInfillField` gives every point of an object the center of its lobe and a
 radial coordinate: 0 at the center, 1 at the surface along the ray from the
-center. `PrintObject::prepare_tpms_radial_fields()` builds it in
+center. `PrintObject::prepare_adaptive_infill_fields()` builds it in
 `bridge_over_infill()`, next to the adaptive cubic octree, because the anchoring
 infill generated there has to match the printed infill. A field is built for
 every mode a region uses, and is shared by the regions using that mode: the
@@ -202,7 +202,7 @@ built for them.
 
 ## Constraints
 
-- With `tpms_adaptive` disabled, or for other patterns, the fill parameters are reset
+- With `adaptive_infill_mode` disabled, or for other patterns, the fill parameters are reset
   to their defaults, so they neither change the infill nor split fill batches.
 - `Layer::get_sparse_infill_max_void_area()` uses the sparser of the two
   densities, as the voids at the center are that large.

docs/HLSD/color-picker.md

@@ -0,0 +1,131 @@
+# Color picker
+
+The color picker is a local HTML dialog hosted by `ColorPickerDialog`, a
+`WebViewHostDialog` subclass. Its header and implementation own the ordered
+selection contract and shared filament conversion. Bridge validation, favorites
+persistence, placement and gettext strings remain private to the implementation.
+Its colors use the existing `ColorRGBA` utility.
+It uses a native title bar and fixed window border, allowing dragging but no
+manual resizing or maximization. Native title-bar colors use the application's
+shared dialog dark-theme update on creation and theme changes.
+Like SpeedDial, the host disables browser zoom accelerators, restores native
+WebView focus on activation and readiness, and synchronizes layout and the macOS
+viewport before repainting the backend. Activation never dismisses this modal
+dialog; focus restoration preserves an active editor and its partial input.
+The initialized page reports
+its intrinsic content height; native code validates the current page identifier
+and bounded numeric height, converts CSS pixels to device-independent window
+size, and fits within the display's work area. Identical sizes are ignored. The
+page observes content rather than viewport height, so resizing does not create
+a feedback loop; oversized content remains scrollable.
+The panel snapshots the triggering color or More Colors button's screen rectangle.
+It aligns below the button, flips above when needed, and clamps to that button's
+display work area on initial display. Later content and DPI changes update only
+the client size, preserving the position chosen by dragging the title bar.
+wxGTK clears the dialog's default
+parent-centering constraint and reapplies its native position after showing,
+bypassing wxGTK's requested-position cache. Absolute top-level placement remains
+subject to the window manager; Wayland compositors control it. The official filament palette's
+existing placement is independent of this custom panel.
+A solid selection contains one color; a gradient contains exactly two ordered
+endpoints. The bridge represents these as `{"type":"solid|gradient",
+"colors":["#RRGGBBAA", ...]}`. RGB input is also accepted and becomes opaque.
+Native validation rejects malformed hex and incorrect cardinality.
+
+The project filament color action and the official filament picker's More Colors
+action enable two-endpoint gradients and independent endpoint alpha. The preset
+combo box reads project colors in their stored vector order locally and applies
+changes through `sync_colour_config`,
+retaining the existing RGB/RGBA profile/project formats and dirty marking.
+Sidebar gradient and segmented multicolor swatches draw colors in the supplied
+order without sorting them.
+Opaque colors use `#RRGGBB`; nonopaque colors use `#RRGGBBAA`, including fully
+transparent alpha `00`. Initial selections, alpha-only edits and cancellation
+retain stored alpha. Ordered
+custom results bypass the official palette's `FilamentColor` set. Choosing an
+official swatch retains its existing palette behavior.
+The Linux sidebar's Change extruder color menu uses this same custom editor and
+the filament swatch anchor, including alpha, ordered gradients and configuration syncing.
+
+Striped colors and gradients with more than two endpoints cannot be represented
+by this editor. A notice explains that the current selection is retained; the
+editor starts from the first color, and unchanged confirmation is a no-op.
+Cancellation is also a no-op. If the WebView backend cannot initialize, a local
+unavailable panel offers Cancel and Escape, without opening a system color picker.
+
+Generic color option fields use an ordinary color button on every platform and
+open the same panel with gradients and alpha disabled. The panel is anchored to
+the field button. Empty or invalid field values remain undefined (the empty
+string), distinct from opaque black. Right-click resets to undefined. Cancel does
+not notify the field; confirmation and reset notify only when its RGB string
+changes. Programmatic assignments remain silent, and reading a field never
+writes legacy favorites.
+
+AMS material settings retain their fixed/AMS swatches and first-level popup. Only
+its custom-color action opens the solid, opaque editor, anchored to that custom
+control. The transient popup releases its grab while the modal is open and returns
+to the same selection on cancellation. Confirmation uses the existing default-color
+and packed RGBA event path. Device permission/status checks remain at the first-level
+entry.
+
+Texture import's color-mapping Add Material action opens a solid, opaque editor
+anchored to the mapping row. The existing filament limit is checked before opening.
+The first-level material popup closes as an action; its callback is copied before
+dismissal, so popup destruction does not invalidate the modal's completion path.
+Confirmation invokes the existing virtual-filament callback once; cancellation
+adds no material.
+
+Native gettext strings are installed at document start. Static page labels and
+palette names use stable English keys; RAL codes, channel symbols, and numeric
+labels remain data. The palette color values do not depend on the UI language.
+The application locale also sets the document language. Numeric editor validation
+uses the application's gettext messages, rather than browser language defaults;
+missing translations fall back to the stable English keys.
+
+The pure color/state regressions run with
+`node --test resources/web/dialog/ColorPickerDialog/colorpicker.test.js`.
+Optional real-browser regressions live beside them in
+`colorpicker.browser.test.js`. They use an existing Playwright installation
+(`ORCA_PLAYWRIGHT_MODULE` can name its module path) and an installed browser
+(`ORCA_BROWSER_EXECUTABLE` can name its executable), without adding a production
+dependency. They cover bridge initialization, capability combinations, invalid
+editor recovery, ordered endpoint alpha, favorites, gettext keys, and live theme
+changes. These browser checks complement native contract/persistence tests; they
+do not establish the full native modal confirmation and favorites journey.
+
+Gradient and alpha capabilities are independent and default off. Unsupported
+gradients are rejected; disabled alpha normalizes the selected result to opaque.
+Favorites retain both capabilities independently of the current caller. The page
+stores alpha as a byte and only converts to percentage when displaying or editing
+opacity, so switching endpoints does not change alpha precision.
+
+The page starts disabled. Each document supplies a page identifier in its ready
+message, receives native initialization, and acknowledges it before native code
+accepts confirmation or favorite updates. Repeated initialization does not reset
+edits, and messages from an obsolete document are ignored. Native WebView message
+handling is deferred and guarded by a lifetime token. Only a validated confirmation
+sets the optional result. Cancel, Escape and native window close leave it empty.
+
+Favorites belong to application configuration, separately from the selected result,
+in the editor configuration returned by `AppConfig::config_path()` under `data_dir()`.
+The `color_picker` section has string `version` equal to `1` and a `favorites`
+string containing a JSON array of typed selections. Native helpers normalize and
+deduplicate this array in order and limit it to 24 entries. Updates replace the
+entire section and immediately call `AppConfig::save()`, so accepted favorite
+changes survive cancellation. Empty arrays are saved explicitly. Core `AppConfig`
+only stores the raw section; color validation belongs to the GUI boundary.
+
+When the section is absent, valid solid colors from `custom_color_list` are imported
+once, without changing that legacy section. The legacy native picker saves decimal
+`r,g,b,a` byte strings; hexadecimal RGB and RGBA strings are also supported. Migration
+strictly validates all four decimal channels and preserves alpha. Gradient strings
+and malformed values are ignored. The new version and an empty array are
+saved even when there is nothing to import. A present section with an unknown or
+missing version is left untouched and disables favorite writes. Malformed version
+1 data is displayed as empty and remains on disk until the user explicitly saves
+a valid replacement. Other configuration sections and project/profile color
+formats are independent of this storage.
+
+Interface colors consume the host's `data-orca-theme` and `--orca-*` contract through
+shared styles. The picker opts into scoped global control roles. Application theme
+changes update UI surfaces without reloading the page or changing color data.

docs/HLSD/focus-mode.md

@@ -0,0 +1,66 @@
+# Focus mode (hiding inactive plates) — High Level Design
+
+## Purpose and scope
+
+"Focus mode" is an entry of the canvas menu in the bottom left corner of Prepare. Turned on (eye
+lit), the 3D view hides the inactive plates and shows the current plate alone, so a project with
+many plates can be worked on one plate at a time. Turned off, every plate is shown. It is a view
+setting: it changes nothing in the model, the slice or the project file, and it does not reach
+plate thumbnails. The choice is kept in the app config as `focus_mode`, off by default.
+
+Preview needs no such option, as it already draws the current plate alone and has its own plate
+toolbar. The assembly view and the Design tab do not lay objects out on plates, so the entry is
+disabled there.
+
+## What is shown
+
+The current plate is drawn with its bed, label and icons; the other plates are not drawn at all. The
+world axes, which Prepare draws at the corner of the first plate, move to the corner of the current
+plate, where Preview draws them.
+
+An object instance is shown when its footprint, the XY bounding box of the convex hulls of its
+volumes, overlaps the current plate, or when it is selected. The test is made per instance, so the
+parts of an object are shown or hidden together, and a wipe tower follows its plate the same way.
+It is geometric rather than the plate membership `PartPlateList` keeps, because an instance stays on
+the plate it was first placed on: an object of another plate that reaches over this one, or one too
+large for any plate, would otherwise be invisible while it takes room on the current plate. A
+selected instance stays visible so that what a selection or a gizmo acts on is never hidden, for
+instance an object picked in the object list on another plate.
+
+## Hiding
+
+A hidden object is neither drawn nor picked. `GLCanvas3D::_update_inactive_plates_visibility()`
+runs at the start of each frame of Prepare. It clears `GLVolume::is_active` on the volumes of the
+hidden instances and deactivates their raycasters, which every render pass, the hover and rectangle
+selection, the shadow and center of mass markers already respect. It also deactivates the raycasters
+of the other plates, whose icons would otherwise still take clicks where nothing is drawn. The state
+persists between frames, so the raycasts made while handling the mouse, such as the anchor of a pan,
+see the same scene as the frame.
+
+Other features clear `is_active` too: gizmos hide the objects they do not edit and show them all
+again when they close. `GLVolume::on_hidden_plate` records which volumes this update hid, so it only
+shows again what it hid itself, and it waits for a gizmo that hides objects to close before doing
+so. A volume another feature made active again is hidden again on the next frame. While Focus mode
+is off and nothing is left hidden, the update returns at once.
+
+## Switching plates
+
+The other plates cannot be clicked while Focus mode hides them, so a compact counterpart of the Preview
+plate toolbar takes their place: a column of plate thumbnails in the top left corner, below the top
+toolbar, shown when the project has more than one plate and no gizmo is open. The thumbnails are the
+ones the Preview toolbar shows (`PartPlate::thumbnail_data`); the canvas rebuilds its textures when
+`Plater::plate_toolbar_image_version()` changes, a counter each consumer tracks on its own so that the
+Preview toolbar's dirty flag is left alone. That counter moves after almost every edit, so the
+thumbnail of the current plate, the only one edited while the others are hidden, is drawn again each
+time, and the other plates' only once an edit to them has invalidated theirs. The current plate has an
+accent border, a hovered one the gray border of the Preview toolbar, empty plates are dimmed and the
+plate number sits in the corner; the tooltip gives the plate name. A click selects the plate and
+clears the selection, as a click on a plate row of the object list does. The column scrolls when it
+does not fit above the 3D navigator or the canvas toolbar. Its scrollbar works as the Preview
+toolbar's, with which it shares its style: it shows only while the mouse is over the column or drags
+the bar, and the mouse wheel scrolls the column either way.
+
+Whatever selects a plate while the others are hidden, the camera moves its target over the new plate
+and keeps its angle, distance and height (`PartPlateList::select_plate()`), so the plate comes into
+view where the previous one was. A zoom to all plates, as after loading a project or adding a plate,
+frames the current plate instead. Turning Focus mode on does the same, so the current plate fills the view.

docs/HLSD/keyboard-shortcuts.md

@@ -53,6 +53,13 @@ Space counts as typing. The speed dial's default is the one bare Space, and
 `MainFrame` leaves it to a focused control that uses Space itself (text fields, buttons,
 combo boxes), so it opens the dial from the canvases and the tab strip only.
 
+`MainFrame::handle_global_shortcut` skips a chord that `KeyChord::edits_text()` reports
+while a text field has the focus (a wx text entry, spin control, web view or ImGui
+InputText), and skips every chord while an ImGui modal is open, as a wx modal dialog
+would. `ImGuiWrapper::owns_key()` reads the active InputText and the popup stack
+directly, since `WantCaptureKeyboard` lags a frame, and is called only when the focus is on
+a visible canvas from `OpenGLManager::create_wxglcanvas()`.
+
 ## Which event a chord matches
 
 Letters, digits and special keys match on `wxEVT_KEY_DOWN`. Its key codes do not depend

docs/HLSD/mesh-repair.md

@@ -0,0 +1,135 @@
+# Mesh repair — High Level Design
+
+## Purpose and scope
+
+Mesh repair turns a broken triangle mesh into closed, outward oriented shells that bound a solid, so that the
+mesh slices predictably and the other mesh tools (booleans, cut, painting) get valid input. It runs on demand:
+the *Fix Model* command of the context menu of an object or part and of the warning icon in the object list, *Fix
+All* and *Fix All Plates* in the context menu of a plate, the prompt the Cut tool shows when a cut leaves open edges,
+the *Repair and import* choice of texture import, and the `--repair` option of the command line. It is built on CGAL
+and is the only repair the application has, on every platform.
+
+`repair_mesh()` in `src/libslic3r/MeshRepair.cpp` does the work on one `TriangleMesh`, and `ModelVolume::repair()`
+applies it to a part: it replaces the mesh only when the repair changed it, and remaps or drops the painting of a
+replaced mesh. The GUI side, `fix_model_with_cgal_gui()` in `src/slic3r/Utils/FixModelByCgal.cpp`, runs it on a
+worker thread for each volume of an object, or for one volume, behind a progress dialog. `repair_mesh()` reports its
+progress between stages through a callback, which cancels the repair by throwing.
+
+## What the repaired mesh is
+
+The repair keeps what the slicer would print from the input. The slicer fills a layer where the winding number of
+the input surface is not zero (`MeshSlicingParams::SlicingMode::Regular` uses Clipper's nonzero fill rule), so:
+
+- Shells crossing each other print as their union. The repair keeps them as separate shells, as the parts of an
+  object are kept, and makes each of them an outward oriented solid.
+- A shell inside a solid that is oriented like it adds nothing, and the repair removes it.
+- A shell inside a solid that is oriented inward is a cavity, and stays one.
+- A whole mesh turned inside out prints as a solid, and the repair turns it outward.
+
+On top of that, it closes holes and cracks, gives inconsistently oriented triangles the orientation of their
+neighbours, drops degenerate, duplicate and stray flat geometry, and removes small self-intersections inside a shell,
+such as slivers and folds. Where none of this applies, it reports the mesh as unmodified and the caller keeps the
+original mesh, its painting and its object id.
+
+A volume is repaired in place and is never split into several parts: splitting by connectivity would turn a cavity
+into a separate solid part and fill it. Each solid of the result is a shell of its own, so *Split to parts* still
+separates them. Open pieces of the input whose borders meet exactly, which are pieces of one surface rather than
+solids, come out as the one shell they form.
+
+## Pipeline
+
+The input is treated as a triangle soup. Every stage after the first only runs on what the previous ones could
+not settle, so a valid mesh passes through quickly.
+
+### Valid parts first
+
+Parts of the input that are connected by vertex indices and are already closed, consistently oriented 2-manifolds
+skip the soup stages and go straight to the shell stages. Merging their points with coincident points of other
+parts would only make non-manifold junctions out of solids that touch, for example parts of an assembly exported
+together or voxels written as separate cubes.
+
+### Soup clean-up
+
+The rest of the soup has its coincident points merged. Triangles with repeated corners are dropped. Coincident
+triangles of opposite orientation are a wall between two solids touching face to face, so they cancel in pairs;
+of the remaining copies of a triangle one is kept. A connected region that would vanish entirely through
+cancelling is a two-sided export instead (every face written in both orientations), and keeps one copy of each
+triangle.
+
+Open edges then get their vertices welded within a tolerance of 1e-4 of the bounding box diagonal, which closes the
+cracks some exporters leave between triangles that should share corners. A vertex is never welded further than a
+quarter of its shortest edge, so welding cannot collapse fine detail. A soup that stays mostly open after welding has
+cracks wider than that tolerance, and is welded again with ten and then a hundred times the tolerance.
+
+### Work units
+
+The soup is cut into units repaired independently and in parallel: its connected parts, except that open parts whose
+bounding boxes touch share a unit, so that cracks and T-junctions between separately exported patches still close.
+
+### Building the mesh
+
+A unit whose edges are each shared by at most two triangles, running in opposite directions, and whose vertices each
+have a single fan of triangles, becomes a `Surface_mesh` directly. Any other unit is oriented first. Triangles are
+flipped so that neighbours across an edge shared by two of them agree, each part keeping the orientation the
+majority of its area had, which keeps inward oriented cavities inward. Edges where that is impossible or that more
+than two triangles share are cut, and each fan of triangles around a vertex gets its own copy of the vertex. If that
+still leaves an invalid mesh, CGAL's `orient_polygon_soup()` orients the unit instead, and the parts it flipped
+against their majority are reversed back. The linear pass exists because `orient_polygon_soup()` is several times
+slower on large soups that need only a few fixes.
+
+### Closing
+
+Compatible borders are stitched, parts that can be stitched once reversed are merged, and borders still open are
+snapped onto each other within the weld tolerance, which closes T-junctions. Exactly degenerate faces are removed.
+
+Holes are filled last. Planar border loops that face each other in one plane, one inside the other, bound a single
+region, such as a missing annulus at the end of a tube or a cap with features standing on it. Such a group is
+triangulated at once with a 2D constrained Delaunay triangulation that fills only the faces at odd nesting depth,
+so the openings inside the region stay open. The patch is used only if it closes every loop with the orientation
+of the triangles around it. Every other loop is filled on its own with `triangulate_hole()`, which uses a 2D
+constrained Delaunay triangulation when the loop is planar. Otherwise it searches the best triangulation among all
+triangles over the loop for loops of up to 100 edges, and among the triangles of a 3D Delaunay triangulation for
+longer ones, as the full search is cubic in the length of the loop. Beyond 200 edges the full search is not even
+used as a fallback, and a fan around the loop's centroid closes a loop nothing else could.
+
+The closed unit is split into its shells. The largest stays in place and the others are copied out, as converting
+the whole mesh again costs seconds on large models.
+
+### Shells
+
+The shells of all units, together with the valid parts set aside at the start, are handled independently and in
+parallel. Shells enclosing no volume, which hole filling makes out of stray flat patches, are dropped.
+
+Self-intersections inside a shell are removed locally with `experimental::remove_self_intersections()`, which
+remeshes the region around them. It is used only for local defects: a shell whose intersections involve more than
+5 % of its faces is left as it is, and a result that changes the enclosed volume by more than 0.1 % is undone. On
+heavily overlapping ornamental models the remeshing otherwise cuts parts down to slivers, while on genuine defects
+it changes the volume by thousandths of a percent. Overlaps left in place slice correctly. Remeshing can cut
+small pieces off a shell, so a shell it changed is split again and its pieces enclosing no volume are dropped.
+
+Shells crossing others are found through their bounding boxes and an AABB tree per shell, and are made outward
+oriented solids. For every other shell the winding number just outside it is summed from the orientation of the
+shells containing it, tested from a point on its largest face. The shell bounds the solid only if the winding
+number is zero on exactly one of its sides; it is then oriented so that the solid is inside, or dropped otherwise.
+
+Crossing shells are not united. Slicing unites them anyway, uniting them exactly costs tens of seconds on models
+made of many overlapping pieces, and it would fuse parts that *Split to parts* should keep apart.
+
+## Robustness
+
+The repair avoids `experimental::autorefine_and_remove_self_intersections()` and corefinement, which can crash on
+messy input, and uses only steps whose failures it can detect. A step that fails keeps its input. CGAL precondition
+failures surface as `repair_mesh()` returning false with the message as the error. The output is written in float,
+as every mesh in the application is.
+
+The result does not depend on thread scheduling. `libslic3r_cgal` is built with `CGAL_LINKED_WITH_TBB`. Units and
+shells are processed in parallel, but each on its own data, and their results are gathered in a fixed order;
+sorts compare complete keys, and the detected self-intersections are put in order before they are used. Snapping
+stays sequential, as its parallel version gives different results from run to run. Holes are filled with the full
+search wherever it is affordable, because the search among Delaunay triangles can choose between equally good fills
+differently from run to run, so only non-planar holes of more than 100 edges may still vary. On some inputs
+`experimental::remove_self_intersections()` itself places a few vertices differently from run to run.
+
+## Verification
+
+`tests/libslic3r/test_mesh_repair.cpp` covers each kind of defect above on small meshes with known volumes.

docs/HLSD/multiline-infill.md

@@ -15,8 +15,9 @@ Outlines of centerlines that cross each other overlap at every crossing, which
 over-extrudes the wall intersections. The line-crossing patterns Grid,
 Triangles, Tri-hexagon and Cubic therefore build centerlines that never cross
 (`FillRectilinear::fill_surface_trapezoidal()`), and so do Adaptive Cubic and
-Support Cubic (`FillAdaptive`); the other patterns outline their usual
-centerlines.
+Support Cubic (`FillAdaptive`). 3D Honeycomb skips `multiline_fill()` and draws
+its N lines itself as parallel copies of each wave, which never cross
+(`Fill3DHoneycomb`). The other patterns outline their usual centerlines.
 
 ## Non-crossing centerlines
 

docs/HLSD/precise-seam.md

@@ -82,9 +82,7 @@ there.
   strong point is placed, no later strong modifier and no weak modifier is
   processed for that perimeter.
 - **Weak:** every weak modifier applies. They are applied from the lowest
-  priority to the highest, so the highest one overwrites overlapping zones. A
-  Blocked modifier that fully contains a perimeter is the exception: it is
-  skipped there (see [Full containment](#full-containment)).
+  priority to the highest, so the highest one overwrites overlapping zones.
 
 A strong modifier without a usable segment, even one whose fragments were all
 discarded, passes the turn to the next one.
@@ -232,20 +230,23 @@ begin and end positions on the source contour.
 ### Full containment
 
 A modifier that covers the whole perimeter has no boundaries on it. The policy
-follows seam painting, where painting a whole perimeter green is a meaningful
-choice and forbidding the seam all round is not:
+follows seam painting, where a whole perimeter can be painted in either color:
 
 - **Seam Enforced** types the whole perimeter, like a perimeter painted green all
   round, with subdivision applied as described under [Weak modifiers](#weak-modifiers).
 - **Seam Neutral** types the whole perimeter Neutral, like an unmarked perimeter,
   clearing painting and lower zones.
-- **Seam Blocked** is skipped for the perimeter, with the full-containment
-  warning. The seam cannot avoid the whole perimeter, so the modifier does not
-  override anything below it: lower zones and painting stay in effect.
-- **Seam Center, Left and Right** are skipped with the same warning: there is no
-  intersection to place the point on.
+- **Seam Blocked** types the whole perimeter Blocked, like a perimeter painted
+  red all round, overriding painting and lower zones. The seam cannot avoid such
+  a perimeter: the seam placer compares Blocked candidates with each other like
+  Neutral ones, so the seam is placed as on an unmarked perimeter. If the
+  perimeter stays Blocked after all weak zones, it is reported in the user
+  warning (see [Diagnostics and warnings](#diagnostics-and-warnings)), so the
+  user can check the modifier.
+- **Seam Center, Left and Right** are skipped with the full-containment warning:
+  there is no intersection to place the point on.
 
-Enforced and Neutral take part in the usual priority order (see
+Enforced, Neutral and Blocked take part in the usual priority order (see
 [Weak modifiers](#weak-modifiers)).
 
 The perimeter is fully contained when the united intervals cover every source
@@ -311,9 +312,9 @@ into every perimeter that has a strong seam.
 `collect_weak_modifier_segments()` extracts the segments of every weak modifier
 before the polygon is modified, so all positions refer to the same contour. Each
 segment becomes a zone with a type and two boundaries, kept in application
-order, lowest priority first. Full containment of an Enforced or Neutral
-modifier becomes a whole-perimeter zone at its place in that order: it has no
-boundaries and takes part in no insertion or helper step below. The boundaries
+order, lowest priority first. Full containment of a weak modifier becomes a
+whole-perimeter zone at its place in that order: it has no boundaries and takes
+part in no insertion or helper step below. The boundaries
 carry their positions on the source contour; these remain as provenance after
 insertion and are not indices into the modified polygon.
 
@@ -384,9 +385,10 @@ G-code export issues it as one non-critical warning with the ID
 `SlicingPreciseSeamWarning`. It is a single line, "Precise Seam: <causes>. Seam
 placement may differ from expected.", because the export warnings dialog shows
 only the first line of each warning. Repeated warning events replace the
-notification instead of appending to it. Except for the "had no effect" cause,
-the causes name the modifier types involved, as the menu names them, in menu
-order and each type once, for example "(Seam Left, Seam Enforced)".
+notification instead of appending to it. Except for the "covers an entire
+perimeter" and "had no effect" causes, the causes name the modifier types
+involved, as the menu names them, in menu order and each type once, for example
+"(Seam Left, Seam Enforced)".
 The causes are:
 
 - **failed to process some intersections (types):** at least one fragment was
@@ -395,8 +397,18 @@ The causes are:
   a Seam Center, Left or Right modifier had more than one segment on a
   perimeter (see [Strong modifiers](#strong-modifiers)).
 - **a perimeter is fully inside a modifier, the modifier was not applied to it
-  (types):** a Seam Center, Left, Right or Blocked modifier was skipped for a
+  (types):** a Seam Center, Left or Right modifier was skipped for a
   perimeter (see [Full containment](#full-containment)).
+- **Seam Blocked modifier "<name>" of "<object>" covers an entire perimeter:**
+  a Seam Blocked modifier covered a whole perimeter (see
+  [Full containment](#full-containment)). Only perimeters whose candidates are
+  all Blocked after all weak zones contribute to this warning, and only through
+  the zone in effect there: `apply_weak_modifiers_to_perimeter()` checks the
+  final types and flags the modifier of the highest whole-perimeter zone when it
+  is Blocked. A lower whole zone is overwritten by it and is not reported. Only
+  the first flagged modifier in print and volume order is named, followed by
+  "(N in total)" when there are several. The type name reuses the menu's
+  translation.
 - **modifier "<name>" of "<object>" had no effect on the seam (it might not reach
   the centerline of the printed perimeter):** a modifier was evaluated on at
   least one perimeter and never gave a segment, full containment or a discarded
@@ -420,6 +432,8 @@ The log records the following diagnostic markers:
 - `[PreciseSeamNoEffect]` for every modifier of the "had no effect" cause, with
   the object and modifier names. Unlike the user warning, the log lists all of
   them.
+- `[PreciseSeamFullyBlocked]` for every modifier of the "covers an entire
+  perimeter" cause, listed the same way.
 
 Failures and recoveries are counted separately. The first 10 of each per
 `init()` call are logged in detail, in parallel processing order; if a limit is
@@ -563,12 +577,14 @@ last modifier would.
   priorities, weak boundaries that coincide or share an edge, enforced
   subdivision, whole-perimeter weak zones with painting and priorities, weak
   zones over painting's oversampled candidates, the warning type masks, usage
-  tracking for the "had no effect" warning, volume sorting of strong and weak
-  groups, restoration of strong points after alignment, raft layer indexing and
-  structured slices. End-to-end tests slice a real object with Precise Seam
+  tracking for the "had no effect" and whole-perimeter Blocked warnings, volume
+  sorting of strong and weak groups, restoration of strong points after
+  alignment, raft layer indexing and structured slices. End-to-end tests slice
+  a real object with Precise Seam
   volumes and check the outer wall starts in the exported G-code: every strong
   mode under several seam positions and with a raft, Enforced and Blocked zones,
-  a modifier with a hole, and the user warning.
+  a perimeter blocked all round under every seam position, a modifier with a
+  hole, and the user warning.
 - [Seam placer tests](../../tests/fff_print/test_seam_placer.cpp) cover
   enforced-patch selection independent of the contour start, fully painted
   contours, duplicate removal, and `Print::apply()` synchronization through type

docs/HLSD/tooltip-illustrations.md

@@ -0,0 +1,131 @@
+# Tooltip illustrations
+
+The texture-displacement panel's tooltips can carry a picture under their text: a still image, or a
+short animation that loops while the tooltip is open. Several settings in that panel describe a shape
+rather than a number - what Rotation turns, what Tile repeats, what Invert turns inside out - and a
+sentence about a shape is read twice and understood once.
+
+## Where a tooltip is drawn
+
+`GLGizmoTextureDisplacement::panel_tooltip()` replaces `ImGuiWrapper::tooltip()` throughout the panel.
+It differs in two ways.
+
+It places the tooltip beside the panel instead of under the mouse. The panel is pinned to the right
+edge of the canvas, so a tooltip following the mouse covers the control it is explaining, and one
+carrying a picture covers most of the panel with it. The tooltip goes to the left of
+`m_tooltip_anchor_min`/`_max` - the panel's own screen rectangle, or the texture picker's while that
+popup is up and the tooltip comes from inside it - and to the right only when there is no room on the
+left. This is the placement the picker popup itself already uses.
+
+ImGui normally keeps a tooltip glued to the mouse and ignores `SetNextWindowPos()`. Orca's imgui
+branch honours a position set for a tooltip (see the `ImGuiWindowFlags_Tooltip` branch of `Begin()` in
+`deps_src/imgui/imgui.cpp`) and still clamps the result inside the canvas, which is what keeps a tall
+tooltip near the bottom edge on screen.
+
+It also gives the tooltip a fixed width rather than one derived from its text, because a picture has
+to be laid out against something, and a column of tooltips that are all one width is steadier to read.
+
+## Where the pictures live
+
+`resources/images/texture_displacement/`, as PNG, JPG, BMP or GIF. A tooltip names them by file:
+
+```cpp
+hover_tip(_u8L("Repeats the texture across the painted area. ..."),
+          { { "tile_off.png", _L("Off") }, { "tile_on.png", _L("On") } });
+```
+
+Several in one tooltip are laid out side by side at equal widths, which is how a setting is shown as a
+comparison - the same model at two values of it. The caption under each is translated; the file name
+is not.
+
+A file that is missing or will not decode is skipped, and a tooltip whose pictures are all missing is
+exactly the text tooltip it was before. So the art for a tooltip can land after the tooltip does, and
+a half-finished set never breaks the panel.
+
+## When a tooltip appears
+
+A tooltip waits for the pointer to rest on its control for 0.45 s. The panel is dense and the tooltip
+lands on the model beside it, so with no wait a sweep from the top of the panel down to Bake flashes a
+dozen large panels over the scene. Once one has just been up, the wait drops to 0.1 s for 0.7 s
+afterwards, so reading several settings in a row stays quick - but not to zero, or that same sweep
+would flash again the moment one tooltip had been seen.
+
+No tooltip appears at all while a control is being used - a slider dragged, a value typed into one, a
+combo open, a layer card being dragged. The pointer sits on the very thing being edited, so a tooltip
+there covers the model exactly while the user is watching it change. The full wait comes back
+afterwards rather than the short one: having just let go of a slider is not a reason to be shown a
+picture of it.
+
+A pointer resting on a control produces no events, and the canvas only renders when something asks it
+to, so the wait has to ask for its own frames, and so does an animation once one is on screen. So does
+a tooltip that has just appeared, animated or not: ImGui hides a window on the first frame it is
+submitted while it measures it, and does so every time a tooltip reappears because those windows are
+recycled, so the frame a tooltip is decided on is never the frame it is seen on. Both use
+`GLCanvas3D::request_extra_frame()`, which ends `on_idle()` with `evt.RequestMore()` and so obliges wx
+to deliver the next idle. `schedule_extra_frame()` is not enough on its own: it only arranges a timer
+whose event an idle event is assumed to follow, and on_idle renders nothing unless the canvas was
+already dirty when it ran. Asking for frames as fast as they come is safe here because which frame is
+drawn comes from the clock, not from the frame count, so a redraw that arrives early simply draws the
+same frame again.
+
+## Decoding and playback
+
+`slic3r/GUI/AnimatedTexture.hpp` decodes a file once and uploads one GL texture per frame. Stills go
+through `wxImage`; GIFs go through `wxGIFDecoder`, whose raw palette indices are composited here frame
+by frame, replaying the disposal method each frame asks for. That replay is what makes an animation
+look continuous: a GIF frame is a sub-rectangle drawn over what came before it, so an animation that
+only re-sends the pixels that changed draws as a flicker of disconnected patches without it.
+
+A frame delay of 0 or 1 hundredths of a second is read as 100 ms, the convention browsers settle on,
+so an animation authored against that plays at the speed it was authored at.
+
+The animation restarts when its tooltip opens, rather than running off a free-running clock: these are
+short loops of one setting going from one value to another, and joining one halfway through shows the
+end of a change the user never saw the start of.
+
+Which frame is drawn is measured on a real clock, not `ImGui::GetTime()`. Nothing in OrcaSlicer ever sets
+`io.DeltaTime`, so it keeps imgui's default of 1/60 per frame and imgui's clock counts frames rather
+than seconds. On a canvas that renders only when asked, that is not a clock at all: an animation driven
+by it crawls while the canvas is idle and races while a moving mouse is rendering it flat out.
+
+## Making one
+
+`scripts/gen_texture_displacement_tips.py` draws the lot, in four languages, picked by what the
+setting actually is:
+
+- **A shaded relief**, for the settings that are about a pattern: Depth, Tile, Tile size, Rotation,
+  Repeat/Mirror, Smoothing, Edge fade, Invert, Blend and the Normal, Fast, Checker and Distortion
+  views. One motif - a ring inside a square frame - runs through all of them, because using one shape
+  everywhere is what lets two pictures be compared: whatever differs between them is the setting,
+  since nothing else is.
+- **A flat mesh of triangles**, for the settings that are about the mesh or about a tool: the paint
+  tools, brush size, the connected-area fill, subdivision, feature-adaptive refinement, remeshing,
+  hard edges, slivers and the wireframe view. These carry the one accent colour in the set, meaning
+  "painted", because that is the only thing in such a picture that is not geometry.
+- **A section**, for Midlevel and for smoothing the geometry. The reason generalises: shading reads
+  slopes, so a height field moved up or down as a whole shades identically to where it started, and
+  any setting whose meaning is *where the surface sits relative to where it was* is invisible from
+  above and has to be drawn from the side.
+- **A flat ramp of greys**, for Mix filaments, Mixed colors and Denoise. Those are about which
+  filament a spot ends up as; lighting one would only add a second thing changing between two
+  pictures meant to differ in one.
+
+The five Mapping pictures are one ball with a checker laid on it five ways, which is the whole of what
+choosing a projection does - except Unwrap, which is not a projection onto the model at all and so is
+drawn as the flat layout it produces.
+
+Captures of the real tool are still the first choice for anything involving a real model or real
+filament colour: Bake, the mixed-colour count on a photograph, Adjust placement, the frame window and
+the UV editor's seam tool have no picture yet for that reason.
+
+Either way:
+
+- Square, around 256 px (192 for an animation, where every frame ships). The tooltip is about 20 em
+  wide, so that is roughly native size on a 100% display and downscales cleanly above it. A single
+  picture is capped at 10 em tall and centred, two side by side take half the width each.
+- Neutral grey. These say what a shape does; colour in one reads as a third thing the setting does,
+  and has to work against both themes.
+- Animations loop seamlessly and stay short - 16 frames at 100 ms, under about 150 KB. They sit in
+  `resources/`, which ships with every copy of the application. A sweep driven by a cosine over the
+  frame count loops with no step, since it starts and ends at the same value and the same rate.
+- No text in the picture. Captions are translated; pixels are not.