The EPS error-meaning test walks src/import and its subdirectories. The
picks and tl! literal scans skip directories named tests, as the undo and
message scans already do, so test modules moved to foo/tests.rs or
tests/<topic>.rs are not read as interface code.
On screen, placed documents (PDF, .ai and .vectorcraft) draw from
bitmaps made in the background. Each bitmap that became ready changed
a generation in the canvas key, so the canvas rendered the whole frame
again. The bitmaps share a 512 MiB budget, and making one dropped the
least recently drawn others, even those on screen: with more than that
on screen, every frame dropped a bitmap it drew and asked for it again,
without end. A bitmap that could not be made (the file can't be read
and there is no preview) also changed the generation and was asked for
again in every frame.
When a bitmap is ready, placed_document::made_between names its file,
and the canvas renders again only where the objects showing it are
(placed_area), as it does after an edit, when the frame shown was
rendered on the UI thread and that part is at most half the frame.
Art of a symbol, a graph design, a pattern or a brush that shows the
file still renders the whole frame.
Bitmaps drawn or made since a frame began are not dropped to make room
for the ones it asks for. They stay past the budget up to 2 GiB. A
bitmap that would take them past 2 GiB is not kept, and its file draws
exactly at that zoom. A bitmap that can't be made shows the
placeholder, does not change the generation, and is not asked for
again.
Docs: docs/target-app-parity.md.
A PNG, JPEG, GIF or WebP image that takes more than the decode
allowance as RGBA (2 GiB, 512 MiB in the web app), such as a 24000 ×
24000 JPEG, was placed with the warning "too large to draw" and then
drew as a crossed gray box on the canvas and was left out of raster
exports. A 16-bit PNG whose decoded samples were past the allowance
was shown the same way, with the same warning, although its RGBA fits.
The renderer now decodes such an image at the largest size, keeping its
proportions, that fits the allowance as RGBA. Each pixel of the result
is the mean of the image's pixels it covers. A PNG that isn't
interlaced is read a row at a time; other images are decoded whole when
their decoded samples fit the allowance. A 16-bit PNG that isn't
interlaced and whose RGBA fits is read a row at a time at its own size.
An image of more pixels than the allowance has bytes still draws as the
crossed box, and so does one whose decoded samples are past the
allowance, other than a PNG that isn't interlaced. The renderer
decodes an image at reduced size only while the result and the memory
reading it takes (the image decoded whole, or the PNG reader's row
buffers) fit beside the images being painted; otherwise the image is
not decoded on that render (on the canvas it draws as the crossed box)
and is tried again on the next render. The document keeps the whole
file for saving and export. A placed document's saved preview past the
allowance is decoded the same way, at the size it is drawn at or at the
reduced size when that is smaller.
Open, Place and the Links panel say "an image of W × H pixels is shown
at reduced size" for an image drawn smaller. They say nothing for an
image drawn at its own size, and they say "too large to draw" for one
that is not drawn at reduced size.
Docs: docs/mcp.md, docs/target-app-parity.md (the crossed box's line
now names an image over the allowance that can't be drawn at reduced
size).
A Drop Shadow, Gaussian Blur, Feather or Photoshop-style filter raster
too large to keep whole is cropped to the view. It was drawn again
only while a later frame's rect, panned back, lay inside the frame it
was made in, so every pan that showed new pixels made it again. For a
Drop Shadow on a 6000 x 4000 pt image in a 2560 x 1440 view at 100% to
400%, a pan took 60 to 84 ms; with Gaussian Blur or Feather, a pan took
158 to 217 ms.
When such a raster is made again at the zoom and rotation of the one
kept for the object, it now also covers a margin around the view: up
to half the view's longer side, while the raster stays within the
8.4 million pixel budget at full size (441 pixels on each side of a
2560 x 1440 view for a 20 pt blur at 100%). Later pans that keep the
view inside the margin draw that raster. The first frame at a zoom, a
zoom step and the frames of a drag make the raster without the margin,
as before. A shadow made over an earlier cropped shadow covers only
the rect the earlier one was made for.
A kept raster is drawn again only after a pan by whole device pixels,
but the wheel, a trackpad and the scroll bars scrolled the view by
amounts that are not whole pixels. The canvas now moves the view by
whole device pixels when it scrolls or is dragged. A scroll by the wheel, a trackpad, a touch screen or a scroll
bar is rounded, and the part of a pixel left over is added to the next
scroll of the same view; it is dropped after a zoom, a turn, Fit or a
document switch. A Hand tool, Space or middle-button drag and a scroll
bar thumb drag round the distance from where the drag began.
The silhouette of a shadow or glow raster is now drawn with art culled
against the raster's own area instead of the view, as filtered content
already is. Before, a group member outside the view cast no shadow
into a raster kept whole, so a pan that showed the member drew it
without its shadow. A cropped raster kept across the margin would have
done the same. The moved silhouette that a drag compares is drawn the
same way.
Docs: docs/target-app-parity.md.
`apps/vectorcraft/tests/it/help.rs` gave the desktop binary 5 seconds
to exit and otherwise reported that the app had started. While
`cargo xtask ci` runs the workspace's tests in parallel, starting the
binary can take longer than that, and both help tests failed although
the binary printed its usage.
The test now reads standard output and standard error to their end on
threads and waits up to 120 seconds for them. It also sets
`VECTORCRAFT_CONTROL_PORT` to a value the app rejects, so a binary that
does not stop at `--help` exits with that error instead of opening a
window, and the usage checks fail.
The renderers share decoded images within a budget of an eighth of the
installed memory, at most 1 GiB. The installed memory was read only on
Linux, so on Windows, macOS and FreeBSD the budget was always 1 GiB,
also on machines with less than 8 GiB.
The installed memory is now read with GlobalMemoryStatusEx on Windows
(through winsafe, which vectorcraft-cli already uses), sysctl
hw.memsize on macOS and sysctl hw.physmem on FreeBSD. The budget rule
is unchanged: an eighth of the installed memory, at most 1 GiB, 1 GiB
where the memory can't be read, and 256 MiB in the web build.
The Type tool's anchor and caret were moved past the inserted markers
only by the menu item in the desktop app. When text.convertListToText
came over MCP or the control channel while the Type tool was editing,
they kept their old byte offsets, and the inserted characters (a bullet
is 3 bytes) could leave an offset inside a character.
The command now ends the Type tool's typing, then moves its anchor and
caret past the characters inserted at or before them. In threaded type,
when the caret's character moved to another frame, the tool edits that
frame, which becomes the selection when it was not selected. The menu
item runs the command without adjusting the selection itself.
Docs: docs/mcp.md.
The reference app's Type › Bullets and Numbering › Convert to Text turns
the bullets and numbers of the selected list paragraphs into editable
text. VectorCraft drew list markers but could not convert them.
Type › Bullets and Numbering › Convert to Text (type.convertListToText,
text.convertListToText) puts each list paragraph's marker at the start
of the paragraph as characters: the bullet, or the number and its
period as the paragraph showed it, then a tab, in the marker's font,
size and color. The paragraph leaves its list. Where the marker's tab
went to the left indent, the paragraph gets a plain left tab stop
there, so the text after the tab starts where it did. Where the
marker's tab went to a stop with a leader, or to a right, center or
decimal stop, a plain stop where the tab ended keeps the converted tab
there without the leader; right, center and decimal stops between the
marker and that place are removed. Past the left indent this applies
only to a paragraph with no tab of its own. In threaded type the
numbers are those the story counted, and a paragraph that goes on into
the next frame is converted once, where it starts. A right-to-left
paragraph with no direction set gets the Right to Left direction when a
letter or roman numeral in front of it would make it run left to right.
The change is one undo step. The Type tool's caret stays next to the
character it was next to, and in threaded type it goes with that
character to the frame it moved to, which becomes the selection when it
was not selected.
With the Every-line Composer a paragraph that holds a tab is broken
line by line, so a converted paragraph can break its lines at other
places than the list paragraph did.
Docs: docs/mcp.md, docs/target-app-parity.md.
i18n: Convert to Text in the 24 catalogs.
aiongg