[Cuis-dev] Icons with path sequence in vector graphics

[Juan Vuletich]

Hi Luciano,

On 2026-06-24 9:12 AM, Luciano Notarfrancesco via Cuis-dev wrote:
> Got it, in a few lines of code I can fully convert path data in that 
> compact standard format to a list of PathCommands, and then I can just 
> compose with a transformation for a given height and position and draw 
> it. Works great!

Good. Glad it works ok.

> Juan, perhaps we should extend VectorEngine>>pathSequence: to support 
> all commands? Or your idea is to convert other commands to this 
> reduced subset (like converting arcs to a list of bezier curves I 
> guess, etc)?

Let me tell a bit about my thoughts when originally writing this stuff.

There's the choice between reifying the path elements vs just making 
them calls. PathCommand is a reification of the canvas API. I wasn't 
sure whether it would be the preferred way.

Then, for things like #drawHandLarge I preferred to find a more 
performant and memory efficient way to do it, even if less elegant. 
Remember we're coming from BitBlt, where everything is very compact and 
super fast. So I did #pathSequence:, packing everything in a (preferably 
literal) FloatArray. But Arcs, like in 
#arcCenterX:centerY:radiusX:radiusY:start:sweep:rotationCos:rotationSin: 
need trigonometry, that is slower than basic arithmetic, so I left it 
out. You can see in the comment at #pathSequence: that I was worried 
about performance of trigonometric functions. I guess the cost of 
trigonometry is dwarfed by the cost of the actual rendering. Maybe we 
should add them after all.

See #drawHandLarge. I found it rather easy to write the FloatArrays 
manually. It is not really different from the SVG way. Still, I 
understand that the icons font shows that we do need to support the SVG 
way, and not just manually writing the FloatArrays. But backtick compile 
time expressions may be used to turn the SVG like commands into literal 
FloatArrays for performance. We get convenience and performance. If you 
do this:

- You'd leave out the geometry transformation of the literal FloatArray, 
and apply it on each call (usually by giving each transformation its own 
morph to hold it, or we could extend the canvas api if needed). This is 
of course to build a single literal FloatArray for each widget.

- I guess this could be done with little code taking advantage of 
SVGPath>>#buildFromXml:defs: in the SVG package. But it would make this 
code dependent on SVG. This also shows there are repeated ideas between 
PathCommand and SVGPath. Some consolidation could be in order... Food 
for thought.

So, the choice is between your likely clean and nice code for turning 
the SVG like spec into PathCommands, and a more complicated but 
potentially more performance use of #pathSequence:. #pathSequence: may 
be worth it if there is a large number of icons, and many are displayed 
at once.

Still, turning them into #pathSequence: FloatArrays at compile time is 
worth doing.

In any case, your code for this will be useful in many other scenarios. 
Please consider making it a separate package, part of SVG, or part of 
the base Cuis image!

Please keep the discussion going. This could lead to better code in base 
Cuis and/or packages, not just your great app.

Thanks,

> On Wed, Jun 24, 2026 at 2:27 PM Luciano Notarfrancesco 
> <luchiano at gmail.com> wrote:
>
>     I've been making my own buttons, knobs, pulldown lists, etc... all
>     sorts of widgets. Some of them draw text, like the label on a
>     button, and I'd like to add optional monochromatic icons. For the
>     sake of simplicity, I'd like to just set the icon as path data,
>     something like this:
>         M784-120 532-372q-30 24-69 38t-83 14q-109
>     0-184.5-75.5T120-580q0-109 75.5-184.5T380-840q109 0 184.5
>     75.5T640-580q0 44-14 83t-38 69l252 252-56 56ZM380-400q75 0
>     127.5-52.5T560-580q0-75-52.5-127.5T380-760q-75 0-127.5
>     52.5T200-580q0 75 52.5 127.5T380-400Z
>
>     I got this from https://fonts.google.com/icons , there you can
>     search the icons you like and click on the image of the icon to
>     copy this path data to the clipboard.
>
>     Then, say it is the icon for a button, the button morph can draw
>     it scaled depending on the morph height, or on the line spacing of
>     the font used for the label. Seems the simplest solution to me,
>     and it would be just one or two lines of path data when creating
>     the button.
>
>     My question is, how do I represent this in Cuis? There is
>     PathCommand and subclasses, but it's not used anywhere in the base
>     image or packages, I didn't find any examples. There's also
>     VectorCanvas>>pathSequence: in a different format, more limited
>     (only supports commands M L C Q, I think).
>
>     What's the correct path for this? What do you suggest?
>
>     Thanks,
>     Luciano
>
>
-- 
Juan Vuletich
www.cuis.st
github.com/jvuletich
researchgate.net/profile/Juan-Vuletich
independent.academia.edu/JuanVuletich
patents.justia.com/inventor/juan-manuel-vuletich
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20260624/d54c4501/attachment-0001.htm>