Too much delayed on-screen feedback for keyboard operation in v.15

[chncwk]

When I use the keyboard to move the control points of the lines, there is a delay of about 1 second before the updated on the screen. and in version13, such results were updated instantly. This problem is related to the size of the font project; the larger the project size, the longer the delay.

Does this problem have anything to do with the new version's enhanced antialiased rendering of lines? I actually prefer the version 13 rendering scheme, visible jaggedness can be visualized on the screen to tips a line is not perpendicular.

Also, please reinstate the hint icon about when the lines are crossed or tangent , without these tips it is not possible to accurately determine whether line intersections have been avoided.

When cutting between two nodes with the knife tool, V15 will not perform the cut operation, but simply add nodes to the line edges.

未标题-2.png (61.91 KiB) Viewed 14367 times

[Erwin Denissen]

When I use the keyboard to move the control points of the lines, there is a delay of about 1 second before the updated on the screen. and in version13, such results were updated instantly. This problem is related to the size of the font project; the larger the project size, the longer the delay.

Does this problem have anything to do with the new version's enhanced antialiased rendering of lines? I actually prefer the version 13 rendering scheme, visible jaggedness can be visualized on the screen to tips a line is not perpendicular.

No, it is not related to the way the outline is drawn. We might be able to improve performance if you send us the font project file.

Also, please reinstate the hint icon about when the lines are crossed or tangent , without these tips it is not possible to accurately determine whether line intersections have been avoided.

You can enable the validation tips through the Validation panel.

When cutting between two nodes with the knife tool, V15 will not perform the cut operation, but simply add nodes to the line edges.

The most recent version should work just fine. If the problem still occurs, do send us the font with specific instructions to reproduce the issue.

[chncwk]

No, it is not related to the way the outline is drawn. We might be able to improve performance if you send us the font project file.
The most recent version should work just fine. If the problem still occurs, do send us the font with specific instructions to reproduce the issue.

The font project has been sent to you via private message

[Erwin Denissen]

We have received the font along with your comments.

This project was created by FC13;
The migration to FC 15 revealed a number of problems
1. The project opening with FC15 conversion time is up to 12 minutes;

We have made an adjustment to the next upcoming update, which should speed up opening font projects from previous versions.

2. The screen update time is too long for moving, deleting, cutting and drawing graphics;

It is indeed slower, but the latest version is not that bad. It is too complex to further optimize it.

3. The Font Export Settings panel does not allow to customize the exported font's name, which does not allow the author to quickly locate the font in third-party software (sort by file name) and compare the version of the font, which is commonly used in the scenarios of quickly deleting and installing fonts;

We will further respond to this comment in this other topic of yours.

4. Cutting between two nodes is fruitless and only adds nodes at line edge ;

It does work, but you need to ensure the start and end of the cut line actually include the outline. If you want to cut through an existing point, then make sure you enable Snap to Points from the View menu. Maybe it should always be "on" with the Cut Contours feature.

5. It is still recommended not to do antialiased rendering of connecting lines between points, it has no positive effect and wastes resources.

FWIW the way we draw the outline is as fast as it can be.

6. Is it possible to add cut contours line directly with a keyboard shortcut after selecting two points with the mouse? This is very common and useful.

Maybe. What shortcut makes sense?

[Bhikkhu Pesala]

Maybe. What shortcut makes sense?

Ctrl+X would be nice if it does not conflict with other uses of Cutting the selected contour to the clipboard, etc.

[chncwk]

We have received the font along with your comments.

Thank you for your response, I still have some questions I hope to follow up on.

[chncwk]

2. The screen update time is too long for moving, deleting, cutting and drawing graphics;

It is indeed slower, but the latest version is not that bad. It is too complex to further optimize it.

Selecting a point and pressing Ctrl+Arrow key 5 or 6 times in a row,

V13.gif (31.05 KiB) Viewed 14125 times

The software (v15) is frozen and can't feedback the operation process.

V15.gif (36.62 KiB) Viewed 14125 times

And I found that the screen update speed is related to the size of the project file, The difference in speed between the two software is double.

[chncwk]

4. Cutting between two nodes is fruitless and only adds nodes at line edge ;

It does work, but you need to ensure the start and end of the cut line actually include the outline. If you want to cut through an existing point, then make sure you enable Snap to Points from the View menu. Maybe it should always be "on" with the Cut Contours feature.

Check "Snap to point" to solve the problem, it is off by default.
The orthogonal auxiliary line that tips snaped target is too thick and black, look not very nice, should change the color and thickness.
The feedback after cutting is also slow.

4.png (17.68 KiB) Viewed 14122 times

[chncwk]

5. It is still recommended not to do antialiased rendering of connecting lines between points, it has no positive effect and wastes resources.

FWIW the way we draw the outline is as fast as it can be.

5.1 Horizontal and vertical control lines are thicker and fainter than diagonal and curved control lines, and this doesn't look natural. Vertical and horizontal lines should naturally coincide with pixel and be the thinnest.

5.2 The control lines look thicker and chunkier than the glyph outline line, which is not only a visual effect problem, but also functionally masks problems with the glyph lines, such as the lines are slightly non-vertical or non-horizontal.

5, 7.png (64.57 KiB) Viewed 14122 times

5.3 Together with the symptoms of problem 2, it is suggested that user should be allowed to turn off anti-aliasing and revert to the real-time feedback speed of older versions until rendering appearance and performance is thoroughly refined.

[chncwk]

6. Is it possible to add cut contours line directly with a keyboard shortcut after selecting two points with the mouse? This is very common and useful.

Maybe. What shortcut makes sense?

The X key in point mode has not been used and is recommended.

7. The Variations panel opens several times and then becomes blank and unmanipulable.

[Erwin Denissen]

6. Is it possible to add cut contours line directly with a keyboard shortcut after selecting two points with the mouse? This is very common and useful.

Maybe. What shortcut makes sense?

The X key in point mode has not been used and is recommended.

We will add X as shortcut for a Knife operation if two points are selected.

7. The Variations panel opens several times and then becomes blank and unmanipulable.

Variations are used with variable fonts. In your case the font has no axes, so there is no variation available.

[Erwin Denissen]

5. It is still recommended not to do antialiased rendering of connecting lines between points, it has no positive effect and wastes resources.

FWIW the way we draw the outline is as fast as it can be.

5.1 Horizontal and vertical control lines are thicker and fainter than diagonal and curved control lines, and this doesn't look natural. Vertical and horizontal lines should naturally coincide with pixel and be the thinnest.

5.2 The control lines look thicker and chunkier than the glyph outline line, which is not only a visual effect problem, but also functionally masks problems with the glyph lines, such as the lines are slightly non-vertical or non-horizontal.

5.3 Together with the symptoms of problem 2, it is suggested that user should be allowed to turn off anti-aliasing and revert to the real-time feedback speed of older versions until rendering appearance and performance is thoroughly refined.

Speed has nothing to do with rendering the glyphs. We have mainly focused on rendering on high dpi monitors, as that is the future.

[Erwin Denissen]

2. The screen update time is too long for moving, deleting, cutting and drawing graphics;

It is indeed slower, but the latest version is not that bad. It is too complex to further optimize it.

Selecting a point and pressing Ctrl+Arrow key 5 or 6 times in a row,
V13.gif
The software (v15) is frozen and can't feedback the operation process.
V15.gif
And I found that the screen update speed is related to the size of the project file, The difference in speed between the two software is double.

Yes, this is clearly an issue. We will look into this, but it is rather complex as we continue to add more features to the software, and that tends to make it slower.

[Erwin Denissen]

4. Cutting between two nodes is fruitless and only adds nodes at line edge ;

It does work, but you need to ensure the start and end of the cut line actually include the outline. If you want to cut through an existing point, then make sure you enable Snap to Points from the View menu. Maybe it should always be "on" with the Cut Contours feature.

Check "Snap to point" to solve the problem, it is off by default.
The orthogonal auxiliary line that tips snaped target is too thick and black, look not very nice, should change the color and thickness.
The feedback after cutting is also slow.

We will make this change with the next upcoming release.

[chncwk]

5.2 The control lines look thicker and chunkier than the glyph outline line, which is not only a visual effect problem, but also functionally masks problems with the glyph lines, such as the lines are slightly non-vertical or non-horizontal.

Speed has nothing to do with rendering the glyphs. We have mainly focused on rendering on high dpi monitors, as that is the future.

Issue 5.2 still has a big impact on FHD displays, maybe the screen resolution can be detected to determine whether to turn on the anti-aliasing switch, so Everybody's satisfied.
Or add a new tip color line for slightly non-orthogonal state?