Jump to content
You must now use your email address to sign in [click for more info] ×

[AD] Pixel alignment snapping is not working as expected (nodes still go to half pixel-locations)


Recommended Posts

Hi everybody,

I try to keep nodes on whole pixels, so I put snapping like this:
- Checked Force pixel alignment
- Checked move by whole pixels
(- snapping is on)

But for some reason I still get half pixels when moving or creating nodes or moving curves.

I'm out of ideas on what I could do wrong here. I always thought putting snapping to these settings should prevent creation of half-pixel positions, but it doesn't seem to work as expected.

Anybody got a clue on what I might be doing wrong or missing here?

Thanks!

 

Link to comment
Share on other sites

The cause of this has been mentioned in quite a few different discussions, but it all comes down to the difference between points on geometric shapes & mapping them to pixel coordinates. This is not the easiest thing in the world to understand (or explain!) but this article is about as good as it gets. In that article, the section beginning with "There are other issues involved in mapping real-number coordinates to pixels" explains why 'Force Pixel Alignment' doesn't do what you would expect.

Note that whether or not Affinity forced alignment to the edges of the pixel grid or to the pixel centers, it would only work for odd or even integer line weights.

All 3 1.10.8, & all 3 V2.4.1 Mac apps; 2020 iMac 27"; 3.8GHz i7, Radeon Pro 5700, 32GB RAM; macOS 10.15.7
Affinity Photo 
1.10.8; Affinity Designer 1.108; & all 3 V2 apps for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 15.7

Link to comment
Share on other sites

44 minutes ago, Friksel said:

Checked move by whole pixels

That has often been mentioned in the forums as causing problems, though I'm sure there are special situations where it's useful. Generally the recommendations seem to be to have it off.

-- Walt
Designer, Photo, and Publisher V1 and V2 at latest retail and beta releases
PC:
    Desktop:  Windows 11 Pro, version 23H2, 64GB memory, AMD Ryzen 9 5900 12-Core @ 3.00 GHz, NVIDIA GeForce RTX 3090 

    Laptop:  Windows 11 Pro, version 23H2, 32GB memory, Intel Core i7-10750H @ 2.60GHz, Intel UHD Graphics Comet Lake GT2 and NVIDIA GeForce RTX 3070 Laptop GPU.
iPad:  iPad Pro M1, 12.9": iPadOS 17.4.1, Apple Pencil 2, Magic Keyboard 
Mac:  2023 M2 MacBook Air 15", 16GB memory, macOS Sonoma 14.4.1

Link to comment
Share on other sites

2 hours ago, walt.farrell said:

That has often been mentioned in the forums as causing problems, though I'm sure there are special situations where it's useful. Generally the recommendations seem to be to have it off.

Thanks @walt.farrell . That's unfortunate, but thanks for the warning. I stop trusting it and putting it off for now.

 

Link to comment
Share on other sites

3 hours ago, walt.farrell said:

That has often been mentioned in the forums as causing problems, though I'm sure there are special situations where it's useful. Generally the recommendations seem to be to have it off.

  @walt.farrell  do you perhaps know if this is caused by the same bug?:

After placing all my artboards on exact pixel locations (so no decimals) and even locking them, just to find out after working a day in the file (not changing those artboards, only adding new ones), that all my artboards are suddenly moved decimal pixels. Causing the slices to be wrong... causing wrong filesizes on the output from the export persona... causing me wondering why locations aren't right in my webprojects... just to find out Designer changed the artboards for some reasons and so all outputs are wrong...

I need to have the exact dimensions on the output files as orginally set in my artboards. So I find myself unlocking all artboards again and putting them back on whole pixels again. I already had to do that a few times only today for this project. As you can imagine it's getting pretty frustrating after a while and it now takes a lot more time to do my project.

Do you perhaps know what is causing this issue? Could this be the same issue as you refered in your last post here?

Anybody have any ideas on what is causing this issue, so I can keep it from occurring everytime again?

Thanks, it would really help to have some knowledge on why this issue keeps on appearing!!

 

Link to comment
Share on other sites

I'm not sure. But have you ensured that both the location and size of the artboards have integer pixel values?

Is your document sized in pixels or in something else like mm?

-- Walt
Designer, Photo, and Publisher V1 and V2 at latest retail and beta releases
PC:
    Desktop:  Windows 11 Pro, version 23H2, 64GB memory, AMD Ryzen 9 5900 12-Core @ 3.00 GHz, NVIDIA GeForce RTX 3090 

    Laptop:  Windows 11 Pro, version 23H2, 32GB memory, Intel Core i7-10750H @ 2.60GHz, Intel UHD Graphics Comet Lake GT2 and NVIDIA GeForce RTX 3070 Laptop GPU.
iPad:  iPad Pro M1, 12.9": iPadOS 17.4.1, Apple Pencil 2, Magic Keyboard 
Mac:  2023 M2 MacBook Air 15", 16GB memory, macOS Sonoma 14.4.1

Link to comment
Share on other sites

26 minutes ago, walt.farrell said:

I'm not sure. But have you ensured that both the location and size of the artboards have integer pixel values?

Is your document sized in pixels or in something else like mm?

Yes, I am absolutely sure I had all artboards in integer values, cause I was doing that on purpose on all artboards today because I don't want blurry graphics on my webproject and so put everything on whole pixels as far is possible. I have have my document in pixels and use pixels everywhere. Both position and size of all artboards were set to integer values.

What I did see though one time today when I was adding a new artboard in an open space suddenly all other artboards were moving on screen as if they needed to re-arrange themselves to make room for a new artboard. That was pretty odd and didn't feel stable at all, especially because they were all on lock. There was no need to make room and I don't know of any function that does that in Affinity neither. But thank god that only happened once today and after that the values of the artboards were still integer values I believe. At least later today I checked all values (and changed some), but even after putting them back to integer values again later today they were on half pixels again. Crazy.

As if Designer is calculating the position of each artboard when a new artboard is placed and then makes mistakes in the calculation resulting in values with decimals.

I'm working in this file whole day now and locked all artboards this morning after putting them to integer values. But at this point I don't trust that lock anymore at all to be honoust.

 

 

Link to comment
Share on other sites

4 hours ago, R C-R said:

The cause of this has been mentioned in quite a few different discussions, but it all comes down to the difference between points on geometric shapes & mapping them to pixel coordinates. This is not the easiest thing in the world to understand (or explain!) but this article is about as good as it gets. In that article, the section beginning with "There are other issues involved in mapping real-number coordinates to pixels" explains why 'Force Pixel Alignment' doesn't do what you would expect.

Note that whether or not Affinity forced alignment to the edges of the pixel grid or to the pixel centers, it would only work for odd or even integer line weights.

Hi @R C-R, I just see your post now, somehow I missed thisone. Thanks for this. I will dive into the article when I have a little more time.

For now, what do you mean by this: "it would only work for odd or even integer line weights."?
I understand you probably mean it's working for either odd or even integer values, but this moment I can't find a reason why that should be either the one or the other. Well, maybe that's in the article.

 

Link to comment
Share on other sites

@Friksel: Could you give us a sample .afdesign file that demonstrates the problem you're having?

-- Walt
Designer, Photo, and Publisher V1 and V2 at latest retail and beta releases
PC:
    Desktop:  Windows 11 Pro, version 23H2, 64GB memory, AMD Ryzen 9 5900 12-Core @ 3.00 GHz, NVIDIA GeForce RTX 3090 

    Laptop:  Windows 11 Pro, version 23H2, 32GB memory, Intel Core i7-10750H @ 2.60GHz, Intel UHD Graphics Comet Lake GT2 and NVIDIA GeForce RTX 3070 Laptop GPU.
iPad:  iPad Pro M1, 12.9": iPadOS 17.4.1, Apple Pencil 2, Magic Keyboard 
Mac:  2023 M2 MacBook Air 15", 16GB memory, macOS Sonoma 14.4.1

Link to comment
Share on other sites

2 hours ago, Friksel said:

For now, what do you mean by this: "it would only work for odd or even integer line weights."?

The article explains all this much better than I can, but this is the best I can come up with for now:

If pixel alignment was always done on pixel centers, for geometric shapes that had odd numbered integer stroke widths (1, 3, 5, etc. px) the strokes would always align perfectly with the pixel grid wherever the stroke was aligned horizontally or vertically on the grid. That is because for odd numbered integer sequences there is always a middle integer, with the same number of integers to either side of it. But that would not work for even numbered stroke widths because for even numbers, there is no middle integer with the same number of integers to either side of it.

But if pixel alignment was always done on the edges of the grid, the opposite would be true -- the strokes would only align perfectly for even numbered integer stroke widths.

For pixel alignment to always work for both even & odd integer stroke widths, one or the other would have to be shifted ½ pixel, depending on which type of alignment was used. Since very often stroke widths in documents are a mix of integer & non-integer values, & regardless of that only strokes aligned horizontally or vertically to the grid will fit perfectly into the pixels of the grid, there is no way to keep every pixel of every stroke completely filled with its stroke color to begin with, & those ½ pixel shifts would frequently cause misalignments even for a mix of even & odd integer widths.

All 3 1.10.8, & all 3 V2.4.1 Mac apps; 2020 iMac 27"; 3.8GHz i7, Radeon Pro 5700, 32GB RAM; macOS 10.15.7
Affinity Photo 
1.10.8; Affinity Designer 1.108; & all 3 V2 apps for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 15.7

Link to comment
Share on other sites

12 hours ago, walt.farrell said:

@Friksel: Could you give us a sample .afdesign file that demonstrates the problem you're having?

Sorry @walt.farrell  I can't/don't share professional projectfiles. When experiencing issues I always try to create a reproduction-file to show the issue, but I can't think of a way to do that in this case. I was hoping somebody here experienced the same issue before ('moving' artboards to portions of pixels) and could help me in the direction of 'don't use that and that tool, cause it's error prone' or 'you forgot this and this setting', or something else I might be missing here.

9 hours ago, R C-R said:

The article explains all this much better than I can, but this is the best I can come up with for now:

If pixel alignment was always done on pixel centers, for geometric shapes that had odd numbered integer stroke widths (1, 3, 5, etc. px) the strokes would always align perfectly with the pixel grid wherever the stroke was aligned horizontally or vertically on the grid. That is because for odd numbered integer sequences there is always a middle integer, with the same number of integers to either side of it. But that would not work for even numbered stroke widths because for even numbers, there is no middle integer with the same number of integers to either side of it.

But if pixel alignment was always done on the edges of the grid, the opposite would be true -- the strokes would only align perfectly for even numbered integer stroke widths.

For pixel alignment to always work for both even & odd integer stroke widths, one or the other would have to be shifted ½ pixel, depending on which type of alignment was used. Since very often stroke widths in documents are a mix of integer & non-integer values, & regardless of that only strokes aligned horizontally or vertically to the grid will fit perfectly into the pixels of the grid, there is no way to keep every pixel of every stroke completely filled with its stroke color to begin with, & those ½ pixel shifts would frequently cause misalignments even for a mix of even & odd integer widths.

Nice resource you're pointing to here. I did a quick read and will continue reading when I have a little more time. Thanks for summing things up a little and completely understandable.

I understand when using strokes there are choices to be made by the software to put colors either in one or the other pixel when we have odd/even width 'issues'. But I need pixel-snapping on fills only and would expect the pixel-snapping to look at the positions of the nodes rather than worrying about strokes and what not, cause the strokes can have all kind of difficult settings adding to the calculations, like what are your choices when you're not using an odd or even strokewidth, but a varying strokesize. For pixel alignment I expected Designer to look at the positions of the nodes only as reference for what pixel it snaps to.

For example like this:

pixel-align-fill.jpg.c683b5d4edf088195bbc8f532837f557.jpg

What I would expect:
When a user starts drawing a shape, like for example this rectangle, the cursor automatically snaps to the closest pixel while moving the mouse or pen. In that case you always have your fills on whole pixels instead of portions of pixels. Yes, strokes are left out of the equation and could be off if you choose the 'wrong' stroke-width, but in my opinion it's perfectly acceptable and understandable that the decision to use 'wrong' stroke widths, so strokes resulting in half pixels, is left to the designer. This way when a designer draws shapes (snapping to a pixel grid), he just sets his stroke to an odd width (1, 3, 5 and so on) and knows for sure all his strokes are rendered on whole pixels too.

And if it is build like this Designer could still throw a warning-message somewhere when a user uses a stroke (or brush) with stroke-widths resulting in pixel-portions and leaving the whole-fixed-pixel path. Just some exlamation mark on some yellow triangle or whatever suites the UI.

I don't see any difficulties in that approuch on the moment, but I could be missing something.

This way it would also make more sense (at least to me) to convert strokes to outlines, because you as a designer can see what pixels Designer has chosen for you to snap to. And the Designer software knows exactly how the full shape looks like, so it can convert it to pixels much better, 'cause it's knowing all details of the shape, like direction of the paths, where it is on the screen and so on.

So this should work on both open and closed curves.

So really what I'm after is just a grid of the size of one pixel for each row and column, where the cursor always snaps to when drawing shapes and nodes.

 

Link to comment
Share on other sites

45 minutes ago, Friksel said:

What I would expect:
When a user starts drawing a shape, like for example this rectangle, the cursor automatically snaps to the closest pixel while moving the mouse or pen. In that case you always have your fills on whole pixels instead of portions of pixels.

Maybe I have misunderstood something about what you expect, but when Force Pixel Alignment is enabled, that is exactly what Affinity does. Try this to see what I mean:

1. Create a new document in Affinity Designer. To keep things simple for this exercise, make it 100 x 100 px or so.
2. Open the Grid & Axis Manager from the View menu. Set it to show a 1 x 1 pixel grid like this:
1364638993_GridAxismanager.jpg.9a9a2f6b7392f17c2d5cef228b7b1d80.jpg
3. If necessary, zoom in enough that the grid is visible. Set the grid line color & opacity to anything you want that makes it easy to see.
4. Enable Force Pixel Alignment, but for now do not enable Move By Whole Pixels.
5. Select the Rectangle Tool & set it to use any Fill color you want & no stroke.
6. Hold down the mouse button & begin drawing a rectangle.

At this point you should see that the rectangle is indeed snapping to pixel boundaries, so that each square of the pixel grid within the rectangle's boundary is completely filled with the fill color you chose. If not, check your settings, because if they are as above that is exactly what should happen.

7. Now, switch to the Move Tool & move the rectangle around on the canvas. Note that as long as Force Pixel Alignment is enabled, the rectangle snaps to the pixel grid boundaries.

8. Repeat this procedure using the Pen Tool to create an arbitrary shape.

Note that the nodes created always snap to the pixel grid boundaries, just like with the rectangle. However, the path of the shape created will not be (& can not be!) confined to the pixel grid boundaries unless all the nodes of the path are sharp ones & aligned on the pixel grid, like the green shape:
1138963256_nodesonagrid.jpg.ead912e625a3d63c45c22891d11dfca0.jpg
The same is true for any other geometric shape whose path can't be aligned to the pixel grid boundaries, like a circle, ellipse, triangle, cog, donut, etc. Likewise, this also applies to rotated or skewed shapes, even the green one unless it is only rotated in 90° increments.

One more thing before I close this longwinded post: Move By Whole Pixels does exactly what it says it does. That means if a node or rectangle coordinate or whatever currently does not have an integer pixel value (like say an x coordinate of 10.2 px), with that option enabled moving it will be constrained to whole (integer) pixel increments (like to 11.2 px or 20.2 px or whatever).

All 3 1.10.8, & all 3 V2.4.1 Mac apps; 2020 iMac 27"; 3.8GHz i7, Radeon Pro 5700, 32GB RAM; macOS 10.15.7
Affinity Photo 
1.10.8; Affinity Designer 1.108; & all 3 V2 apps for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 15.7

Link to comment
Share on other sites

9 minutes ago, R C-R said:

One more thing before I close this longwinded post: Move By Whole Pixels does exactly what it says it does. That means if a node or rectangle coordinate or whatever currently does not have an integer pixel value (like say an x coordinate of 10.2 px), with that option enabled moving it will be constrained to whole (integer) pixel increments (like to 11.2 px or 20.2 px or whatever).

My problem with this is that ‘Move By Whole Pixels’ is presented as a child of ‘Force Pixel Alignment’, but when enabled it overrides (rather than simply modifying in some way) its parent option. :S

Alfred spacer.png
Affinity Designer/Photo/Publisher 2 for Windows • Windows 10 Home/Pro
Affinity Designer/Photo/Publisher 2 for iPad • iPadOS 17.4.1 (iPad 7th gen)

Link to comment
Share on other sites

16 minutes ago, αℓƒяє∂ said:

My problem with this is that ‘Move By Whole Pixels’ is presented as a child of ‘Force Pixel Alignment’, but when enabled it overrides (rather than simply modifying in some way) its parent option. :S

But isn't that just a way to modify what the 'parent' option does?

The way I think of it is either things can be forced to align with points on the pixel grid or not. If they are, then there is an additional option to force them to move by integer values. But if they are not being forced to align to any point on the grid, the coordinate values of the grid are irrelevant. IOW, the 'parent' option forces the tools to snap to grid coordinate values, but they may or may not be integer values, depending on if the 'child' option is enabled or not.

BTW, maybe it is worth mentioning that grid alignment snapping is totally independent of the other snapping options -- even when Snapping on the toolbar & none of the snap options of the Pen or Node tool are enabled, grid alignment snapping still works when Force Pixel Alignment is enabled.

All 3 1.10.8, & all 3 V2.4.1 Mac apps; 2020 iMac 27"; 3.8GHz i7, Radeon Pro 5700, 32GB RAM; macOS 10.15.7
Affinity Photo 
1.10.8; Affinity Designer 1.108; & all 3 V2 apps for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 15.7

Link to comment
Share on other sites

1 hour ago, R C-R said:

Maybe I have misunderstood something about what you expect, but when Force Pixel Alignment is enabled, that is exactly what Affinity does. Try this to see what I mean:

...

Thanks for your effort and the time you take to help.

For some reason with my working project this Force Pixel Alignment was still resulting in portions of (floating) pixels. As a test I followed your steps exactly from start to finish with Move By Whole Pixels turned off on a new document exactly as you described. Just to find out all drawing is indeed snapping to whole pixels. But than I started moving the just drawn curves (on all whole pixels) around and saw they are still resulting in half pixels some times. So I figured something must be different in my configuration in comparison with yours.

So I did some switching in other snapping options and found out that Force Pixel Alignment isn't on top of it all (highest priority). There are certain other snapping options that still cause Designer to chose off pixels. Like 'include margin midpoints', but also other important snapping options, like 'snap to grid'. Look at this:

In my opinion this is confusing, misleading and error prone and the unexpected endresult remains hidden to designers while designing, because we (well at least I do) assume all graphics will be snapped to pixels when 'Force pixel alignment' is set to true. In the video you can see clearly the node is bing placed on a half pixel because it's prefering the margin snapping over pixel forcing. But you can only see that now while looking very closely on a zoomed-in grid of 100x100 and even a visible pixel-grid turned on. Normaly we don't work like that and need to trust Designer to always pick/snap to whole pixels if we set 'Force pixel alignment' to true. Why else would we turn that setting on and the setting is a prominent button on the UI that's different to other snapping options.

So it seems like this is causing the half-pixel behaviour for drawing graphics. And I also found out now that Designer has a 'pixel work' preset that turns off all other snapping options making sure forcing to pixels works. So yes, that preset (all other snapping turned off) will probably always work with pixel work and always chose whole pixels. But if we need to turn off all snapping options just to work on whole pixels that seems a little too black and white / one or the other to me. I want to use both and consider that to be a very standard expected workflow; I use snapping options a lot, but I only want to enable force pixel alignment next to that as a top priority(-correction) at the end.

 

 

Link to comment
Share on other sites

10 minutes ago, haakoo said:

No, this is to be expected because the snapping to object geometry is also on.
I f yo have a shape with absolute integers and absolute even numbers it snaps just like it should.
 

No, it's not. Look at the video. All objects have absolute integer position and size values and still result in half pixels because of other snapping options. Force to pixel alignment should always be highest priority in my opinion. Otherwise you as a designer would never know for sure (unless you check every node you draw in closeup) if your designs are on whole pixels so can't trust the setting anymore. Or you need to turn off your other snapping options, which would be not very efficient to me. I love those snapping options and use them a lot, but I still want to let Designer pick the nearest pixel after calculating its snapping result-value.

Also, sometimes you receive files by clients (or use some older work when you didn't place nodes on whole pixels) and don't want the existing shapes to affect the way you draw new shapes. Now it does.

 

Link to comment
Share on other sites

6 minutes ago, Friksel said:

There are certain other snapping options that still cause Designer to chose off pixels.

Indeed there are already many snapping options available in all the Affinity apps, & if you have tried out the betas you know there are more to come.

However, there is no way for any of the apps to predict which ones any particular user may want to use individually or in various combinations at different times in different projects for different reasons. IOW, there is no "standard workflow" that applies to everyone. So all I can suggest at this point is to spend some time learning how they work, alone & in combinations, to get it to do whatever you want.

I am not suggesting that will be as easy or intuitive as you might like. For one thing, there is no simple 'global' higher to lower priority, as you might expect. There are far too many available snapping options for that! Among the things considered are proximities, object & bounding box geometries, candidate options, visibility, which tool is in use, & so on.

All 3 1.10.8, & all 3 V2.4.1 Mac apps; 2020 iMac 27"; 3.8GHz i7, Radeon Pro 5700, 32GB RAM; macOS 10.15.7
Affinity Photo 
1.10.8; Affinity Designer 1.108; & all 3 V2 apps for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 15.7

Link to comment
Share on other sites

This may be silly, but I wonder if some additional automatic behaviors (or, possibly, snapping-related options) are needed.

For example, if both "force pixel alignment" and "snapping to midpoints" are enabled perhaps all objects should (optionally?) be forced to even pixel dimensions. Then snapping to midpoints couldn't disturb the pixel alignment.

-- Walt
Designer, Photo, and Publisher V1 and V2 at latest retail and beta releases
PC:
    Desktop:  Windows 11 Pro, version 23H2, 64GB memory, AMD Ryzen 9 5900 12-Core @ 3.00 GHz, NVIDIA GeForce RTX 3090 

    Laptop:  Windows 11 Pro, version 23H2, 32GB memory, Intel Core i7-10750H @ 2.60GHz, Intel UHD Graphics Comet Lake GT2 and NVIDIA GeForce RTX 3070 Laptop GPU.
iPad:  iPad Pro M1, 12.9": iPadOS 17.4.1, Apple Pencil 2, Magic Keyboard 
Mac:  2023 M2 MacBook Air 15", 16GB memory, macOS Sonoma 14.4.1

Link to comment
Share on other sites

16 hours ago, walt.farrell said:

This may be silly, but I wonder if some additional automatic behaviors (or, possibly, snapping-related options) are needed.

For example, if both "force pixel alignment" and "snapping to midpoints" are enabled perhaps all objects should (optionally?) be forced to even pixel dimensions. Then snapping to midpoints couldn't disturb the pixel alignment.

This is exactly what I mean. In my opinion 'Force Pixel Alignment' (in some javascript frameworks called 'snapToPixel') is not the same kind of snapping as all other snapping functions. All the other snapping options are for layout purposes, while Force Pixel Alignment is related to the technical output. So I really believe Force Pixel ALignment should be treated different and should have highest rank, 'cause it's not about a layout thing per se, but about having technical sharp digital images when using raster-formats as output. Preventing all kind of side effects from happening when using in animations (online).

 

Link to comment
Share on other sites

18 hours ago, walt.farrell said:

This may be silly, but I wonder if some additional automatic behaviors (or, possibly, snapping-related options) are needed.

For example, if both "force pixel alignment" and "snapping to midpoints" are enabled perhaps all objects should (optionally?) be forced to even pixel dimensions. Then snapping to midpoints couldn't disturb the pixel alignment.

At the least, this would have to be implemented as a (probably large) number of options because in a lot of workflows snapping to object bounding boxes, midpoints, key points, etc. is exactly what is wanted, regardless of what that does to pixel alignment.

As it is, with the snapping 'ranking' (if you want to call it that) based on proximity, candidate lists, visibility, & so on, it is adaptable to many different workflows without the need for even more options that would make the Snapping Manager panel that much more complex & confusing than it already is.

Besides, forced pixel alignment can't make any path edges sharp if they curve or are not perfectly horizontally or vertically aligned to the pixel grid, so even when that is exactly what is wanted, it only works for a very limited number of geometric shapes, & there is still the issue of even/odd stroke widths to deal with even for them.

All 3 1.10.8, & all 3 V2.4.1 Mac apps; 2020 iMac 27"; 3.8GHz i7, Radeon Pro 5700, 32GB RAM; macOS 10.15.7
Affinity Photo 
1.10.8; Affinity Designer 1.108; & all 3 V2 apps for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 15.7

Link to comment
Share on other sites

20 hours ago, R C-R said:

At the least, this would have to be implemented as a (probably large) number of options because in a lot of workflows snapping to object bounding boxes, midpoints, key points, etc. is exactly what is wanted, regardless of what that does to pixel alignment.

No, not at all. It only needs to be implemented the right way: at the end of all snapping options. No matter how many options you have or whatever combinations you make with them; snapping to pixels should always be the last stage after all snapping options calculated. And yes, there is ALWAYS a priority order of snapping options, because that's just the way code works. When you move your node the software iterates somehow over all snapping options and picks some option that suits best or a combination of options are calculated together to get a result, but you always have a position value at the end of the equation somehow. And that value should only then be FORCED to a whole pixel. Where all inbetweens of a curve lie doesn't matter, you only snap nodes to pixels.

 

Link to comment
Share on other sites

23 minutes ago, Friksel said:

When you move your node the software iterates somehow over all snapping options and picks some option that suits best or a combination of options are calculated together to get a result, but you always have a position value at the end of the equation somehow.

As has been mentioned several times now, the 'somehow' is base on proximity. The process does not calculate & combine different snapping options, it picks one to use, based on what is nearby.

All 3 1.10.8, & all 3 V2.4.1 Mac apps; 2020 iMac 27"; 3.8GHz i7, Radeon Pro 5700, 32GB RAM; macOS 10.15.7
Affinity Photo 
1.10.8; Affinity Designer 1.108; & all 3 V2 apps for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 15.7

Link to comment
Share on other sites

1 hour ago, R C-R said:

As has been mentioned several times now, the 'somehow' is base on proximity. The process does not calculate & combine different snapping options, it picks one to use, based on what is nearby.

You seem to not wanting to read and understand my posts. I discontinue this discussion now.

 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...

Important Information

Terms of Use | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.