RyanJEC

Couldn't agree more, that's one of the reasons we've put these examples up.  However I should re-emphasise that the examples don't represent everything that's possible with scripting, even at this early stage.  It's ok to find the examples underwhelming:
Note: "just to demonstrate" and "basic"  But like I said, constructive feedback is welcomed, just don't worry that this is all you're going to get.
This next bit is mainly for any devs who might be reading this.
The Javascript API is built entirely on top of the C API.  Actually, it's built on top of a header-only C++ SDK that minimally wraps the C API so we don't have to worry about explicitly deallocating any handles that might be used.  We've not cheated and called directly into the Affinity backend from the Javascript layer, it's all going through the C++ wrappers and therefore through the public C API functions.  This is great for testing, as tests written in Javascript exercise all abstraction layers.  We will likely release the C++ headers along with the C headers.
There is a low-level Javascript API that is as similar to the C API as possible, which has the benefit of reducing the amount of documentation we have to write.  There are some differences between function signatures, but essentially they are the same, with each C function "projected" into Javascript land.  We then provide a set of JS files that wrap those exposed JS functions into ES6 classes and hide a lot of the boring boiler-plate that no-one cares about.
For maximum performance, you'd use the C or C++ layer.  For convenience, you'd use the high level JS layer, which is what the examples use. For Javascript consumers who want to design a different OOP layer, they are free to require() the API functions directly and wrap them up however they like.  I would say that as a dev coming from a mainly C/C++ background, I was surprised at how performant the Javascript levels have turned out to be.
 

Hey Ash, thanks a lot for bringing that into Designer.

By the way, Is it possible to apply the Vector Warp that contains pixel layers inside?
Unfortunately, the current Vector warp doesn't move or change the pixels inside.

I'll attach an example, this definitely would make the Vector warp more consistent to work with Paintings.



 
 
A real example attached, trying to deform the Vector with painting

Hi, I'll attach a video to show the result,

it doesn't seem to apply correctly, considering the colors of connected shapes.

But I see when the Shape is Empty it works nice,
but when having color actually the Color tolerance doesn't seem to be used.

Is a bug, or am I doing something wrong? 😅
2023-02-17 07-23-43.mp4    

Instead of using pressure profiles on strokes to control the line thickness/width from the start of a stroke to the end of the stroke maybe allow us to change the line thickness at each point. Then have them blend between each of the points. This would give greater control and save time on creating the strokes you want. I find using the pressure profiles to be cumbersome when selecting the graph points and when you have a long stroke it's harder to get the results you want.

Just wanted to add I use "Cycle Selection Box" to set "Regular Bounds" to get pixel precision on Group/Compound layers for UI design so an option to make it a permanent toggle is essential for my workflow. Currently hitting this button every time I switch layers can be tedious.

Just wanted to add I use "Cycle Selection Box" to set "Regular Bounds" to get pixel precision on Group/Compound layers for UI design so an option to make it a permanent toggle is essential for my workflow. Currently hitting this button every time I switch layers can be tedious.

Instead of using pressure profiles on strokes to control the line thickness/width from the start of a stroke to the end of the stroke maybe allow us to change the line thickness at each point. Then have them blend between each of the points. This would give greater control and save time on creating the strokes you want. I find using the pressure profiles to be cumbersome when selecting the graph points and when you have a long stroke it's harder to get the results you want.

Instead of using pressure profiles on strokes to control the line thickness/width from the start of a stroke to the end of the stroke maybe allow us to change the line thickness at each point. Then have them blend between each of the points. This would give greater control and save time on creating the strokes you want. I find using the pressure profiles to be cumbersome when selecting the graph points and when you have a long stroke it's harder to get the results you want.

Instead of using pressure profiles on strokes to control the line thickness/width from the start of a stroke to the end of the stroke maybe allow us to change the line thickness at each point. Then have them blend between each of the points. This would give greater control and save time on creating the strokes you want. I find using the pressure profiles to be cumbersome when selecting the graph points and when you have a long stroke it's harder to get the results you want.

Instead of using pressure profiles on strokes to control the line thickness/width from the start of a stroke to the end of the stroke maybe allow us to change the line thickness at each point. Then have them blend between each of the points. This would give greater control and save time on creating the strokes you want. I find using the pressure profiles to be cumbersome when selecting the graph points and when you have a long stroke it's harder to get the results you want.

You guest it, I would animate asset from Affinity Designer. You can have the StudioLink like what you have in Affinity Publisher. Still would complete the workflow for vector/infographic/cartoon animators.
Even Procreate manage to this feature to their pixel drawing app. I hope to see such app in your suite.

Hardware/GPU Acceleration on Windows should be top priority for 1.9 update in all the apps.

I couldn't disagree more with this..
You're right that as a graphics designer you don't need instant access to Publishing tools. However, it's very common for people who work with graphics to both have pixel and vector graphics in their art. I know that it's possible to jump between Photo and Designer via the file menu, but this takes time since the document have to close and re-open in the other app.
Since the release of Publisher I open up all my Design/Photo documents in Publisher since that gives me access StudioLink all pixel and vector tools. (When opening in Publisher I of course choose not to convert artboards to spreads, since I want to keep the document as is). After I'm done and want to export my different artboards and slices, I have to jump into Designer or Photo to do this, since the Export Persona is missing in Publisher. I can understand that the ExportPersona is missing in Publisher, since you normally don't work with artboards/slices in here and therefore don't need the option be setup different export-settings per slice/artboard. But since we don't have the ExportPersona in Publisher I really think there's a strong argument to implement StudioLink to Photo and Designer.

Why give publishers better tools for working with mixed pixel/vector graphics than actual graphical artists? I really don't see the logic in this..

I would like to see One Point, Two Point, and even Three Point Perspective guide system/tools.
Would be very helpful in creating scenes, architectural designs, aligning characters properly.

If I get time it'll get done for 1.7.

I would like to see One Point, Two Point, and even Three Point Perspective guide system/tools.
Would be very helpful in creating scenes, architectural designs, aligning characters properly.

The ability to output as pages and not just spreads will be added soon.
 

.