Ballonseide

I have several different photo programs, some new, some old. One old one is Adobe Photo Deluxe Home Edition 4, which I downloaded for free from Internet Archives - https://archive.org/ and, although it;s old, it will download on Windows 10 and it has some things more recent ones don't, such as a Tools item called LINE. You can quickly and easily draw straight lines of any color or thickness, in any direction you like, as many times as you like. I can't understand Affinity being unable to do something so simple!

Suggestions like these are the perfect example why some stuff in AP is just plain broken. That has got nothing to do with Adobe indoctrination (I don't care either way, I never used Photoshop). A bad workflow is just that, a bad workflow. Drawing straight angled lines on a pixel grid should be a matter of a few clicks and easy as pie. Period. If you need to first create a vector object, then rasterize it, something's already gone horribly wrong – let alone if you have to switch to an entirely different app and back again.
There may be tools in AP that work better than Photoshop's, or that just work differently. I applaud that. I have no preconception on how things should work, other than that they should work and that tools need to enable me to do my work efficiently. If that requires learning or re-learning, fine. But the pixel and brush tools are not examples of that. As far as line drawing is concerned, more than half a decade after AP was first released, they're simply still not working right, to the point of being useless for some types of work, as is well-documented in this thread.

Suggestions like these are the perfect example why some stuff in AP is just plain broken. That has got nothing to do with Adobe indoctrination (I don't care either way, I never used Photoshop). A bad workflow is just that, a bad workflow. Drawing straight angled lines on a pixel grid should be a matter of a few clicks and easy as pie. Period. If you need to first create a vector object, then rasterize it, something's already gone horribly wrong – let alone if you have to switch to an entirely different app and back again.
There may be tools in AP that work better than Photoshop's, or that just work differently. I applaud that. I have no preconception on how things should work, other than that they should work and that tools need to enable me to do my work efficiently. If that requires learning or re-learning, fine. But the pixel and brush tools are not examples of that. As far as line drawing is concerned, more than half a decade after AP was first released, they're simply still not working right, to the point of being useless for some types of work, as is well-documented in this thread.

Suggestions like these are the perfect example why some stuff in AP is just plain broken. That has got nothing to do with Adobe indoctrination (I don't care either way, I never used Photoshop). A bad workflow is just that, a bad workflow. Drawing straight angled lines on a pixel grid should be a matter of a few clicks and easy as pie. Period. If you need to first create a vector object, then rasterize it, something's already gone horribly wrong – let alone if you have to switch to an entirely different app and back again.
There may be tools in AP that work better than Photoshop's, or that just work differently. I applaud that. I have no preconception on how things should work, other than that they should work and that tools need to enable me to do my work efficiently. If that requires learning or re-learning, fine. But the pixel and brush tools are not examples of that. As far as line drawing is concerned, more than half a decade after AP was first released, they're simply still not working right, to the point of being useless for some types of work, as is well-documented in this thread.

Yes, the Pen tool works as a substitute for some purposes. But Pen will generate a vector object, with all that entails. This thread is about the Pixel and Brush tools and about being able to lay down lines on a rasterized layer (i. e. drawing pixels directly). This was broken before because "Continue last stroke" (when holding Shift) had erroneous behavior (at least on macOS). That was fixed in AP version 1.7.0, as I wrote above. You can now click with the Pixel/Brush tool to lay down an origin object, hold Shift, click somewhere else and get a proper line between both points.
What's still missing, though, is an option to constrain a line to right angles. Right now, to draw a perfectly horizontal pixel line, you have to zoom in to 400 % or so and carefully place the second pixel at the exact same image height as the first. Very tedious. I think Shift+Alt would be an obvious candidate for this as it is not currently used, at least in the Mac version. (Or it is, but it just duplicates what Alt alone does (color picking). I don't think there's any use for having color picking on Alt+Drag and Shift-Alt-Drag as well.)
Also, a visual preview of the line you're about to draw would be very useful (when holding down Shift). Right now, you're basically drawing blind – you only know what the line is gonna end up like when you've drawn it, meaning you have to do a lot of undo/retry.

Indeed!
And yes, you can use the Pen tool... unless you're trying to draw something exotic – like an arrow... (And no, the Arrow tool does not make it easier either.)
Please fix the Brush tool's "continue last stroke" feature so we can use it for quick and basic pixel line drawing! It can't be that difficult.

I don't know about Windows but on Macs, the Shift key works (kinda) as indicated in the Status Bar: ; that is, to "continue last stroke." But there are several problems with that:
1. From what I can tell, it actually continues the last brush stroke -- just clicking without dragging isn't considered a brush stroke as far as this feature is concerned, even though that creates a spot of paint on the canvas.
2. There is an exception to this: on the first use of the Paint Brush tool on a new document, a click without dragging is considered a brush stroke, but after that it is not ... so AFAIK, it is once per opened document, with no way to 'reset' it so the next click without drag will work.
3. As long as the start of the (brush) stroke is done with a drag, shift-clicking on another point will connect the end of the dragged stroke with that point with a straight line, & it will continue to work like that for subsequent shift-clicks.
4. But there is also a problem with #3 -- if you manage to get a straight line segment by shift-clicking & then shift-drag for the next segment, creating a gap with an unconnected segment.
I think that covers everything, or at least enough to say it is well & truly broken! 

This is a big problem for me as well—currently, there is simply no way to work with "whole pixels only" if this is desired/required.
 
I also second the idea of one global check box that takes care of this. Or at least an option that can be set for individual files, if the former is too much to ask given the complex nature of the problem.
 
I also think it is important to recognize that this not just a problem of snapping. That alone has its issues. But for example, a simple drag-resize operation on a pixel or image layer with "Move by whole pixels" snapping enabled will yield a perfectly located boundary box—and yet the content of the box can still get resized with sub-pixel precision, namely if you use one of the diagonal handles, which by default cause aspect-ratio-correct resizing of the content, usually producing non-integer pixels. (Ignoring aspect ratio by holding Shift does work around this problem—but then you effectively lose control over your aspect ratio entirely, which is even worse.)
 
I also do not agree, as it has been suggested alsewhere, that aspect ratio-correct resizing should always use floating-point precision because otherwise the aspect ratio would not be perfectly preserved. Such precision can be required in some cases, and it's good that it's possibe to work this way; but other use cases do not require this last bit of precision and rather suffer from it. A proposed "whole pixels only" option could simply cause all pixel values in transform operations to be rounded. With anything but very small image sizes, the remaining precision will still be more than sufficient for many use cases, and the need for the whole "watching the Transform panel and correcting the undesired sub-pixel values" part would disappear completely.
 
I really hope this will be solved in some future update, for right now it is the single biggest workflow obstacle in Affinity Photo for me—a big headache, to be honest.

That is, of course, true, and inevitably so. But that's just the point: Affinity Photo is not a simple bitmap image editor, and neither does it just store simple bitmaps—not even for pixel layers. This is obvious because the pixels in those layers can have non-integer positions and non-integer sizes. That's the problem. If everything were just square pixels at integer coordinates, I would have nothing to complain about. What I—and apparently some other users—want is precisely an option to always place pixels at integer coordinates, for the very reason that otherwise you have to deal with fractions of pixels (and the way this is dealt with by Affinity Photo causes both visual and usability problems).

I don't believe this is correct. It very much depends on the pixel count of the image you're working with. I come from photography, and I can state confidently that a 5000 x 4000 pixel image scaled to 4167 x 3333 pixels does not in any way look pixelated even though the "correct" scaling size would be 4166.666666 x 3333.333333 pixels. And with small image sizes it very much depends on the goal pursued whether a result that is layed out in some (pseudo-)sub-pixel manner is more desirable or not.
 
Also, I don't see why floating-point pixel values displayed on a whole-pixel grid should not themselves produce some aliasing. (Perhaps less.) This would only be properly prevented by having a true sub-pixel grid that had sufficient resolution not to be detectable by the viewer.
 
The fundamental issue I see here is the whole-pixel grid that is used for display (and for export to most image formats) by Affinity Photo. Anything other than actual whole pixels must introduce some sort of oddity in the visual result. (See my previous post on that.)
 
Edit:
 
And also, you're right of course that some users would not be happy with whole-pixels only. (While others would. I wouldn't venture a guess on how many on either side.) That's why it's proposed to be a (default-off) option.

Let me put it this way: The only way to display sub-pixels is to simulate displaying sub-pixels, some way or another. Theoretically, this could be done such that the user would not notice it. But that's not how Affinity Photo works, or any other image editing software that I know of, so the point is merely academic. (Hence the qualifiers.) In practice, you have to live with significant drawbacks. I suspect for Affinity Photo a conscious decision was made to swallow some specific drawback and gain some advantage for vector- or floating point-based functions in return. What I would prefer is an option that would let the user decide what is more important to him, and enable him to work the way he needs to work.

This is a big problem for me as well—currently, there is simply no way to work with "whole pixels only" if this is desired/required.
 
I also second the idea of one global check box that takes care of this. Or at least an option that can be set for individual files, if the former is too much to ask given the complex nature of the problem.
 
I also think it is important to recognize that this not just a problem of snapping. That alone has its issues. But for example, a simple drag-resize operation on a pixel or image layer with "Move by whole pixels" snapping enabled will yield a perfectly located boundary box—and yet the content of the box can still get resized with sub-pixel precision, namely if you use one of the diagonal handles, which by default cause aspect-ratio-correct resizing of the content, usually producing non-integer pixels. (Ignoring aspect ratio by holding Shift does work around this problem—but then you effectively lose control over your aspect ratio entirely, which is even worse.)
 
I also do not agree, as it has been suggested alsewhere, that aspect ratio-correct resizing should always use floating-point precision because otherwise the aspect ratio would not be perfectly preserved. Such precision can be required in some cases, and it's good that it's possibe to work this way; but other use cases do not require this last bit of precision and rather suffer from it. A proposed "whole pixels only" option could simply cause all pixel values in transform operations to be rounded. With anything but very small image sizes, the remaining precision will still be more than sufficient for many use cases, and the need for the whole "watching the Transform panel and correcting the undesired sub-pixel values" part would disappear completely.
 
I really hope this will be solved in some future update, for right now it is the single biggest workflow obstacle in Affinity Photo for me—a big headache, to be honest.

PS to my above: Another aspect to this complex that in my opinion speaks for the need of a "whole pixels only" option is the contradiction inherent in having rasterized layers with sub-pixel values but showing them on the image not as half pixels, but as dimmed color over the whole pixel that the bounding box cuts through. (And of course, this is what is exported to pixel-based file formats as well.) Simply said, a pixel layer with size 2.5 x 2.5 pixels will in actuality be a 3.0 x 3.0 pixel layer, only the bounding box will be shown as 2.5 x 2.5 pixels (at the correct location). What this layer does to the image is display the innermost 2.0 x 2.0 pixels as one would expect, but the remaining 0.5 pixels (in each dimension) will go beyond the bounding box; to my eye, they appear like a partly transparent full-pixel addition next to the inner "normal" pixel layer. This is certainly not proper behavior, and in any case not what anyone manipulating pixels would expect. (If anything, one would expect Affinity Photo to actually work this a finer grid and display the non-whole pixels up to the boundary box, at full opacity (or whatever) and no further.)
 
And from simply inspecting the boundary sections of sub-pixel layers one can also easily tell that this has an effect on the scaling result. A 13 x 8 layer scaled down to 10.8 x 6.6 layer looks different than the one that results from manually setting this layer to 11.0 x 7.0 pixels. (I know, aspect ratio gets changed.) I can't claim this to be objective, but visually, I greatly prefer the look of the latter, and I'd presume many other users do, too. The semi-transparent pixels at the boundary of the 10.8 x 6.6 layer just don't look like what is meant to happen when a whole-pixel layer is scaled down.
 
Of course, all this, in the end, is simply a consequence of the fact that pixels (in any practical sense) are indivisible, as others have stressed already. Displaying non-whole pixels is inherently problematic and, to some extent, physically impossible. The current implementation in Affinity Photo is merely a workaround, not a solution to this fundamental problem.

This is a big problem for me as well—currently, there is simply no way to work with "whole pixels only" if this is desired/required.
 
I also second the idea of one global check box that takes care of this. Or at least an option that can be set for individual files, if the former is too much to ask given the complex nature of the problem.
 
I also think it is important to recognize that this not just a problem of snapping. That alone has its issues. But for example, a simple drag-resize operation on a pixel or image layer with "Move by whole pixels" snapping enabled will yield a perfectly located boundary box—and yet the content of the box can still get resized with sub-pixel precision, namely if you use one of the diagonal handles, which by default cause aspect-ratio-correct resizing of the content, usually producing non-integer pixels. (Ignoring aspect ratio by holding Shift does work around this problem—but then you effectively lose control over your aspect ratio entirely, which is even worse.)
 
I also do not agree, as it has been suggested alsewhere, that aspect ratio-correct resizing should always use floating-point precision because otherwise the aspect ratio would not be perfectly preserved. Such precision can be required in some cases, and it's good that it's possibe to work this way; but other use cases do not require this last bit of precision and rather suffer from it. A proposed "whole pixels only" option could simply cause all pixel values in transform operations to be rounded. With anything but very small image sizes, the remaining precision will still be more than sufficient for many use cases, and the need for the whole "watching the Transform panel and correcting the undesired sub-pixel values" part would disappear completely.
 
I really hope this will be solved in some future update, for right now it is the single biggest workflow obstacle in Affinity Photo for me—a big headache, to be honest.