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

Aligned objects not actually aligned


Recommended Posts

5 hours ago, Hangman said:

 

That's not how anti-aliasing works... Anti-aliasing uses semi-transparent pixels to simulate smoothing, so by the very nature of having semi-transparent pixels you will see a change in colour peeping through which is a blend between the top and the underlying colours...

Its working wrong.

Yes that is how it works…If i have a single shape and a background. Not when I have two shapes next to one another and no logical way of the background color peeping through.

 

If two objects are one next to another taking up 30% of a pixel and 60% of a pixel, the semitransparency of one should be added to the semi transparency of the other altogether, because there's no background VISIBLE THERE to contribute to the pixel's final color output!!! Just as how there's no background visible WHEN YOU DO perfectly pixel align —because they are ALIGNED!!! one next to another! with m a g n e t s

Let me draw this in an another way, if I perfectly-force-pixel-align two shapes (and there's no gap), I then GROUP THEM, RASTERIZE THEM, and start moving them without force-pixel-alignment, NO gaps would EVER show because there isn't any space for the background to peep through because they were perfectly magnetically snapped in the first place!! This is how it should work if they werent rasterized in the first place.

I don't care! how all of it works, and I don't care about any more explanations that just explain to me how something works..that's WRONG!

I haven't checked affinity forums and was working on a project and again encountered gaps now with STROKES, the underlying color of the stroke is peeping at the edge. It took me again here. This is unbelievable! I should apply a stroke and GO. I don't care! why I can't, I should, and anyone who gives two cents about developing great software would care too.1442618330_Screenshot2021-08-14at20_53_34.thumb.png.cfb65178a8157dca43c933e78ec306ee.png

1106431925_Screenshot2021-08-14at20_53_51.thumb.png.7488503c87b59cde2a68726c0ec39ead.png

Imagine where would the computer world be right now if all the way back people snarked suggestions of fixing technical limitations and literal bugs in how software works. I can't imagine a more depressing thought. 

Hackintosh running Big Sur 11.2.3, Coffe Lake i3 with UHD630 graphics

MacBook (Early 2015) running macOS Mojave

iPad Pro 11-inch (1st generation) running iPadOS 13.5

Vista PC in the attic 

Link to comment
Share on other sites

21 hours ago, konstantnnn said:

Not when I have two shapes next to one another and no logical way of the background color peeping through.

The background is able to peep through because the edges of both adjoining, perfectly pixel aligned graphics are rasterised and anti-aliased so they can be displayed on your screen, so the edges themselves are now semi-transparent regardless of their perfect pixel alignment.

This is how all vector graphics software works regardless of who makes it, can you think of any vector software that doesn't demonstrate this issue?

21 hours ago, konstantnnn said:

if I perfectly-force-pixel-align two shapes (and there's no gap), I then GROUP THEM, RASTERIZE THEM, and start moving them without force-pixel-alignment, NO gaps would EVER show because there isn't any space for the background to peep through because they were perfectly magnetically snapped in the first place!! This is how it should work if they werent rasterized in the first place.

Correct if you mean converting to a single object, e.g., exporting your original three iPhone images to a JPG file. That JPG file if opened in AD will no longer display the hairlines because there are no longer any rasterised, anti-aliased, adjacent edges between what used to be three adjacent images.

21 hours ago, konstantnnn said:

I don't care! how all of it works, and I don't care about any more explanations that just explain to me how something works..that's WRONG!

The point is, it's not wrong, it's a technilogical limitation of how rasterising and anti-aliasing an object-based vector graphic on a pixel based LCD screen works. If you were able to view this on a vector monitor the issue wouldn't exist.

It appears to be wrong to your way of thinking but it's not wrong from a technological point of view. I'm sure at some point in the future technology will move on and new ways of displaying vector graphics will be developed but for now, this is where we're at.

I think we can agree to disagree but the facts are the facts. I'm not a computer scientist but I'm sure there are other more eminently qualified people who can describe in far more detail how the rasterisation and anti-aliasing of vector objects works when displaying them on a pixel based display and what the techological limitations are.

Fact - the white or dark lines are be caused by anti-aliasing of an application where the two regions intersect. Turning off the anti-aliasing eliminates these lines.

If the hairlines bother you why not simply turn off the anti-aliasing as suggested in my previous post?

 

21 hours ago, konstantnnn said:

I haven't checked affinity forums and was working on a project and again encountered gaps now with STROKES, the underlying color of the stroke is peeping at the edge.

I'm unsure how you've constructed you current graphic but I would construct it like this and then there would be no visible gaps? I've made the vertical line orange just to show the three shapes...

Can you either upload just the graphic itself or explain how you've created it so we can understand why you are seeing the gap?

Joins.thumb.jpg.6ad2257cb4a0531e3509ad693a001bf7.jpg

Affinity Designer 2.4.1.2344 | Affinity Photo 2.4.1.2344 | Affinity Publisher 2.4.1.2344
Affinity Designer 1.7.3 | Affinity Photo 1.7.3 | Affinity Publisher 1.10.8
MacBook Pro 16GB, macOS Monterey 12.6.8, Magic Mouse

Link to comment
Share on other sites

Quote

The background is able to peep through because the edges of both adjoining, perfectly pixel aligned graphics are rasterised and anti-aliased so they can be displayed on your screen, so the edges themselves are now semi-transparent regardless of their perfect pixel alignment.

We are talking about images that are not rasterized now. Un rasterized images. We are talking about how does a vector program interpret and pixel-display raster objects. An outside frame of every image imported into Affinity can be looked as a vector rectangle. We're talking about adjacent OBJECTS having arbitrary GAPS.

The question is awfully simple, should there be a gap between two adjacent objects? To make it simpler for us to understand, I googled the definition of adjacent,  "next to or adjoining something else". Next to. It's next to. Should there be an arbitrary gap to something that's magnetically snapped together?

It's awfully simple.

It's so, amazingly simple.

Should there be a gap between gapless snapped objects?

I don't care if they are at Retina resolution, 20X resolution, Infinite vector resolution, on Mars, on Jupiter, on my or my sister's computer, in milimiters, inches, meters set to seventy decimal places, half pixels, quadpixels or seventy bilionth-part of a pixel. Should there be a gap between gapless snapped objects? To objects that are ending and starting on the same physical number. The same number. 

The answer is obviously no!

Quote

It appears to be wrong to your way of thinking

I think this is common sense. This isn't anything crazy, to think two supposedly gaplessly adjacent objects — implied both by the "magnet" icon of the snapping tool and the literal position numbers ending in one place and at the same place beginning the other — and implied by the "infinite zoom" paradox of the program where it's obvious that this is a rendering glitch and the logical outline - literal position information is pretty clear about this. There's no place for the background to peep through. They are adjacent. Wikidictionary again? Or?

5 hours ago, Hangman said:

The background is able to peep through

And it shouldn't. 

5 hours ago, Hangman said:

why not simply turn off the anti-aliasing as suggested in my previous post?

Because I seriously thought you were britishly sarcastic. All of my images and graphics will start to look like bad Windows 95 graphics? What kind of question is …that………….. At this point, a much more relevant question would be "why use this program" again

5 hours ago, Hangman said:

This is how all vector graphics software works regardless of who makes it, can you think of any vector software that doesn't demonstrate this issue?

Keynote comes to mind, there are no gaps with all straight-aligned images and halfpixel/.3333 pixel stuff and freehand and etc and etc. When you do a degree turn and rotate it then that's the only time it ever shows this. Which means that the problem partially or completely is solvable in the first place, like Keynote already did non-rotated objects (which my main issue is about). Keynote already solved it (look above). When you rotate it, there is an issue in Keynote, but I do know if those engineers cared enough they would fix that as well. It is solvable.

Technical limitations are meant to be broken. That's how you make better software. That's what feedback forums are all about and all for. That is the purpose of filing feedback

I see no point in utterly defending a technical limitation instead of saying "yup, hope they fix it". You're using it wrong is not a proper answer. 

5 hours ago, Hangman said:

I think we can agree to disagree but the facts are the facts.

I still think this is a joke. You can't possibly say that you agree that gaps should appear on perfectly adjacent objects. You're the man!

 

 

 

Shifting gears

Correct me if I'm wrong, but a part of the confusion maybe also comes from the thought "how should the dispalay engine treat snapped sub-opacity antialiased edges". Isn't it? Let's have an example. I have an object (could be a square image, or a literal square, doesn't really matter — to the "outline view", it's just a square so that's why I use the term object/square/image interchangeably throughout this post).

1) My image is mostly pixel aligned, but there's a single vertical line of pixels on the right which the image doesn't fill fully. In fact, the image covers just about 0,000002% of those pixels.

2) When I bring a second image and snap it to the first one, logically (the program, PDF engine, outline view and snapping engine) know that they are one next to another. The display engine, however, almost acts to ignore this. The display engine is looking at that single vertical line of pixels, and literally it's like it's saying "well, these pixels are filled by an image, so let me start rendering from the next line where there are no pixels filled"!

The display engine almost seems to fail to understand that, yes, these pixels are filled by an image, but there is still more room to be filled. In fact, there is 99,9999998% of room left empty, but the display engine seems to ignore that and to count this very binary — either its full or empty.

This is a flaw of the engine. And when you keep zooming in, it's almost as if you're shaking the program to wake up from a hangover; it's reducing and reducing and reducing the gap as you keep zooming in and zooming in and zooming in — but it's an infinite cat and mouse game.

My issue is with all of this, and the way I'm proposing it is to let the logical way win.

If the developers started going from that, upwards, from the core idea to the technology, they would make a superior display engine.

I don't care if it's a huge leap or (or for) a small insignificant thing. That's what I would do if I knew how to code. If I had a team. That's what Steve Jobs's core vision was when he made the first mac. That's the right thing to do. That's how I approach all of my design work.

 

Document.zip

Hackintosh running Big Sur 11.2.3, Coffe Lake i3 with UHD630 graphics

MacBook (Early 2015) running macOS Mojave

iPad Pro 11-inch (1st generation) running iPadOS 13.5

Vista PC in the attic 

Link to comment
Share on other sites

5 hours ago, Hangman said:

The background is able to peep through because the edges of both adjoining, perfectly pixel aligned graphics are rasterised and anti-aliased so they can be displayed on your screen, so the edges themselves are now semi-transparent regardless of their perfect pixel alignment.

This is how all vector graphics software works regardless of who makes it, can you think of any vector software that doesn't demonstrate this issue?

Correct if you mean converting to a single object, e.g., exporting your original three iPhone images to a JPG file. That JPG file if opened in AD will no longer display the hairlines because there are no longer any rasterised, anti-aliased, adjacent edges between what used to be three adjacent images.

The point is, it's not wrong, it's a technilogical limitation of how rasterising and anti-aliasing an object-based vector graphic on a pixel based LCD screen works. If you were able to view this on a vector monitor the issue wouldn't exist.

It appears to be wrong to your way of thinking but it's not wrong from a technological point of view. I'm sure at some point in the future technology will move on and new ways of displaying vector graphics will be developed but for now, this is where we're at.

I think we can agree to disagree but the facts are the facts. I'm not a computer scientist but I'm sure there are other more eminently qualified people who can describe in far more detail how the rasterisation and anti-aliasing of vector objects works when displaying them on a pixel based display and what the techological limitations are.

Fact - the white or dark lines are be caused by anti-aliasing of an application where the two regions intersect. Turning off the anti-aliasing eliminates these lines.

If the hairlines bother you why not simply turn off the anti-aliasing as suggested in my previous post?

 

I'm unsure how you've constructed you current graphic but I would construct it like this and then there would be no visible gaps? I've made the vertical line orange just to show the three shapes...

Can you either upload just the graphic itself or explain how you've created it so we can understand why you are seeing the gap?

Joins.thumb.jpg.6ad2257cb4a0531e3509ad693a001bf7.jpg

Take a look at the jointing curve in the "Artboard 2" of the document! Enter pixel view, or even make the insides of the clock hand darker. It's pretty jarring. 

Could you provide me a solution to thatDocument.zip

Hackintosh running Big Sur 11.2.3, Coffe Lake i3 with UHD630 graphics

MacBook (Early 2015) running macOS Mojave

iPad Pro 11-inch (1st generation) running iPadOS 13.5

Vista PC in the attic 

Link to comment
Share on other sites

@konstantnnn I can see your way of thinking, and you almost had me convinced of your way of seeing things. Then I started thinking about technically how it could be implemented (many (many) years ago I was a (not very good) programmer). As I started digging into things, I realised the key point that hasn't been addressed here - the layers have a stacking order. Your rectangles are visually next to each other but they are on a different plane (aka z-index).

See the attached document. Four non-pixel aligned rectangles, the top two are on different layers and so on a different plane to each other. The bottom two rectanges have been moved onto the same plane of existance by merging the curves and hence show no AA effect and they are stilll separate objects. Use the pixel view mode to see.

I don't have time to go into all the details of the why, but if you start moving away from a simple case of two rectangles and into more complex setups it quickly becomes an intractable problem. E.g. have a shape cross that boundary below one rectangle and above the other. Maybe that shape has a blend mode, maybe it has transparancy, maybe it's a compound with a different winding mode. It's a hard problem.

AA-planes.afdesign

Link to comment
Share on other sites

10 hours ago, konstantnnn said:

Take a look at the jointing curve in the "Artboard 2" of the document! Enter pixel view, or even make the insides of the clock hand darker. It's pretty jarring. 

Could you provide me a solution to thatDocument.zip

This is a known issue and relates to the stroke alignment. Stroke Inside creates the artifacts you are seeing. Supposedly setting Stoke Outside should correct the issue, which it does but I've noticed that Stroke Outside then creates a new issue with artifacts (see below middle, you may need to zoom into the image to see the problem).

502994437_StrokeBug.thumb.jpg.31d0a008558acd048fc6e4456dd6c663.jpg

The workaround in this instance is to use Stroke Centre which eliminates both issues.

The issue has been reported previously here and has been raised with the Dev team to look into...

I would be inclined to raise this as a new 'bug' or 'issue', especially in light of the additional artifacts introduced with your particular graphic when using Stoke Outside.

Affinity Designer 2.4.1.2344 | Affinity Photo 2.4.1.2344 | Affinity Publisher 2.4.1.2344
Affinity Designer 1.7.3 | Affinity Photo 1.7.3 | Affinity Publisher 1.10.8
MacBook Pro 16GB, macOS Monterey 12.6.8, Magic Mouse

Link to comment
Share on other sites

@konstantnnn Firstly, let me preface this reply by saying, I agree with everything you are saying 110% BUT the point I've been trying to convey (perhaps very unsuccessfully) is, that it's really not that simple as I think @BofG is illuding to as well...

I'm doing my best to try and explain both the complexities, together with possible workarounds (solutions would perhaps be the wrong terminology here I think).

23 hours ago, konstantnnn said:

Should there be a gap between gapless snapped objects?

Absolutely not - but equally you have to understand the techonological limitations we are dealing with here. I appreciate (as you've eloquently stated) that you're not really interested in the technical aspects.

23 hours ago, konstantnnn said:

There's no place for the background to peep through.

I would happily post numerous OpenGL links to the complexities of rendering and anti-aliasing in terms of Multisampling, Box Filtering, Coverage and Primitave Edges but I really do understand this is perhaps not what interests you with regards to this issue (I get it, I have no problem with that). I'm absolutely not trying to defend any corner here, the point I've been trying to make is that with the limitations in current technology, implementing things like Multisampling could and likely would have a BIG detrimental impact on software performance to the extent that people would no longer be raising the issue of the visible hairlines/gaps but would instead be complaining about poor application performance.

23 hours ago, konstantnnn said:

The background is able to peep through - and it shouldn't. 

In a perfect world, again I agree 110%

23 hours ago, konstantnnn said:

Why not simply turn off the anti-aliasing as suggested in my previous post?

Because I seriously thought you were britishly sarcastic. All of my images and graphics will start to look like bad Windows 95 graphics? What kind of question is …that………….. At this point, a much more relevant question would be "why use this program" again

Glad you appreciate the nuances of British sarcasm (it's one of the few things we're good at)... 😂

This is a bit of a two-sided coin, the harline issue is a purely on-screen visual problem and a direct result of anti-aliasing rendering techniques. As such it has no impact on printed images, i.e., offset litho printing or high-resolution inkjet printing but of course it does impact raster images for online use. My suggestion to turn off anti-aliasing in AD was meant in terms of, if it annoys/frustrates you from a visual working standpoint, then turning it off would overcome that (as in the hairlines would no longer be visible) and would have no impact if your artwork was for print.

Clearly if the end use is on-screen, for web, then you wouldn't disable anti-aliasing unless you were going for an early space invaders/asteroids video game look, (I'd assumed, righly or wrongly, that was a given).

23 hours ago, konstantnnn said:

I think this is common sense. This isn't anything crazy, to think two supposedly gaplessly adjacent objects — implied both by the "magnet" icon of the snapping tool and the literal position numbers ending in one place and at the same place beginning the other — and implied by the "infinite zoom" paradox of the program where it's obvious that this is a rendering glitch and the logical outline - literal position information is pretty clear about this. There's no place for the background to peep through.

This really is where the nuances of Multisampling vs Performance potentially come into play, that's not to say that with ever improving processor performance this couldn't be addressed moving forward (though you always have to consider the lowest common demoninator where computer performance is concerned/supported). This was the initial response from Serif with regards this very issue (albeit toward the end of 2015).

Quote

You will get this hairline in any vector program to a greater or lesser extent whenever two edges are exactly the same value... It's a side-effect of the way the rasterisation routine works... There are ways to reduce the effect, but to solve it completely really needs a different approach to the rasterisation (that nobody uses because it provides worse results in other cases). The effects will change based on the exact zoom level and position of the objects on a sub-pixel, but they will always be there. The easiest way to get rid of these is simply to extend objects to overlap in ways that don't matter, and to overlap and 'Add' objects of the same colour to form one object from two that used to butt up to each other. You could also try using the advanced blending options (the cog on the Layers panel) with your objects selected and adjust the antialiasing ramp to include more of the pixels.

We will continue to try to improve this over time, but it is an inherent problem with any vector drawing program (although some do deliberately distort the values you asked for in order to reduce the appearance of this effect, so they seem to be working better - although you can make them fail if you know how...)

 

23 hours ago, konstantnnn said:

Me: Can you think of any vector software that doesn't demonstrate this issue?

You: Keynote comes to mind...

This is all well and good but as soon as you want to produce a repeating pattern using triangles, hexagons or any other shapes using angles other than 0° or 90° then you'd be facing the same problem and Keynote is not AD. I appreciate what you say about their rendering when using squares, I have no idea the rendering techniques used in Keynote, they could simply be very basic, (they are certainly not as advanced as AD) hence no visible hairlines on vertical and horizontal shapes, you'd have to ask an Apple engineer.

 

23 hours ago, konstantnnn said:

Shifting gears

Correct me if I'm wrong, but a part of the confusion maybe also comes from the thought "how should the dispalay engine treat snapped sub-opacity antialiased edges". Isn't it? Let's have an example. I have an object (could be a square image, or a literal square, doesn't really matter — to the "outline view", it's just a square so that's why I use the term object/square/image interchangeably throughout this post).

1) My image is mostly pixel aligned, but there's a single vertical line of pixels on the right which the image doesn't fill fully. In fact, the image covers just about 0,000002% of those pixels.

2) When I bring a second image and snap it to the first one, logically (the program, PDF engine, outline view and snapping engine) know that they are one next to another. The display engine, however, almost acts to ignore this. The display engine is looking at that single vertical line of pixels, and literally it's like it's saying "well, these pixels are filled by an image, so let me start rendering from the next line where there are no pixels filled"!

The display engine almost seems to fail to understand that, yes, these pixels are filled by an image, but there is still more room to be filled. In fact, there is 99,9999998% of room left empty, but the display engine seems to ignore that and to count this very binary — either its full or empty.

This is a flaw of the engine. And when you keep zooming in, it's almost as if you're shaking the program to wake up from a hangover; it's reducing and reducing and reducing the gap as you keep zooming in and zooming in and zooming in — but it's an infinite cat and mouse game.

My issue is with all of this, and the way I'm proposing it is to let the logical way win.

If the developers started going from that, upwards, from the core idea to the technology, they would make a superior display engine.

I don't care if it's a huge leap or (or for) a small insignificant thing. That's what I would do if I knew how to code. If I had a team. That's what Steve Jobs's core vision was when he made the first mac. That's the right thing to do. That's how I approach all of my design work.

Whilst I don't disagree with you, I think if you had this conversation with any software engineer they would be able to tell you, far more eloquently than I ever could, why this approach is currently likely not possible/impractical.

Who knows, maybe that will all change in v2.0 of Affinity's software. I'm not a software programmer, my knowledge is relatively limited and maybe things will change with regards rendering engines/techniques moving forward to address this issue, not only in AD but in pretty much all vector software.

Maybe you can pose the question/issue in the Affinity Support and Questions forum. I think it will elicit a minefield of opinions but the hope would be an update from Serif as to the current viability of improving this anti-aliasing issue... (just my 2 cents worth).

There are easy workarounds, though they are just that just that, workarounds, e.g., experiment with the Contour tool, it does a very good job of 'overcoming' this issue. Take for example a 700 x 700px donut shape or a 500 x 500px square (or any suitable shape using any dimensions), split the donut in half so it takes up 50% of the circle, duplicate it and flip it so you have two adjoining, perfectly pixel aligned shapes to make a complete donut or duplicate the square and snap it so it appears adjacent to the first square. In both instances you will see the hairline/gap issue. Make the shapes 2px smaller in width and height then add a 1px contour (with no stroke) to either. Result, overlapping vectors the same size as the original shapes but exhibiting no gap/hairlines on-screen or on export to any raster image format.

Is it the perfect solution, no, of course not but it's a viable option for now me thinks...

Affinity Designer 2.4.1.2344 | Affinity Photo 2.4.1.2344 | Affinity Publisher 2.4.1.2344
Affinity Designer 1.7.3 | Affinity Photo 1.7.3 | Affinity Publisher 1.10.8
MacBook Pro 16GB, macOS Monterey 12.6.8, Magic Mouse

Link to comment
Share on other sites

1 hour ago, Hangman said:

@konstantnnn Firstly, let me preface this reply by saying, I agree with everything you are saying 110% BUT the point I've been trying to convey (perhaps very unsuccessfully) is, that it's really not that simple as I think @BofG is illuding to as well...

I'm doing my best to try and explain both the complexities, together with possible workarounds (solutions would perhaps be the wrong terminology here I think).

Absolutely not - but equally you have to understand the techonological limitations we are dealing with here. I appreciate (as you've eloquently stated) that you're not really interested in the technical aspects.

I would happily post numerous OpenGL links to the complexities of rendering and anti-aliasing in terms of Multisampling, Box Filtering, Coverage and Primitave Edges but I really do understand this is perhaps not what interests you with regards to this issue (I get it, I have no problem with that). I'm absolutely not trying to defend any corner here, the point I've been trying to make is that with the limitations in current technology, implementing things like Multisampling could and likely would have a BIG detrimental impact on software performance to the extent that people would no longer be raising the issue of the visible hairlines/gaps but would instead be complaining about poor application performance.

In a perfect world, again I agree 110%

Glad you appreciate the nuances of British sarcasm (it's one of the few things we're good at)... 😂

This is a bit of a two-sided coin, the harline issue is a purely on-screen visual problem and a direct result of anti-aliasing rendering techniques. As such it has no impact on printed images, i.e., offset litho printing or high-resolution inkjet printing but of course it does impact raster images for online use. My suggestion to turn off anti-aliasing in AD was meant in terms of, if it annoys/frustrates you from a visual working standpoint, then turning it off would overcome that (as in the hairlines would no longer be visible) and would have no impact if your artwork was for print.

Clearly if the end use is on-screen, for web, then you wouldn't disable anti-aliasing unless you were going for an early space invaders/asteroids video game look, (I'd assumed, righly or wrongly, that was a given).

This really is where the nuances of Multisampling vs Performance potentially come into play, that's not to say that with ever improving processor performance this couldn't be addressed moving forward (though you always have to consider the lowest common demoninator where computer performance is concerned/supported). This was the initial response from Serif with regards this very issue (albeit toward the end of 2015).

 

This is all well and good but as soon as you want to produce a repeating pattern using triangles, hexagons or any other shapes using angles other than 0° or 90° then you'd be facing the same problem and Keynote is not AD. I appreciate what you say about their rendering when using squares, I have no idea the rendering techniques used in Keynote, they could simply be very basic, (they are certainly not as advanced as AD) hence no visible hairlines on vertical and horizontal shapes, you'd have to ask an Apple engineer.

 

Whilst I don't disagree with you, I think if you had this conversation with any software engineer they would be able to tell you, far more eloquently than I ever could, why this approach is currently likely not possible/impractical.

Who knows, maybe that will all change in v2.0 of Affinity's software. I'm not a software programmer, my knowledge is relatively limited and maybe things will change with regards rendering engines/techniques moving forward to address this issue, not only in AD but in pretty much all vector software.

Maybe you can pose the question/issue in the Affinity Support and Questions forum. I think it will elicit a minefield of opinions but the hope would be an update from Serif as to the current viability of improving this anti-aliasing issue... (just my 2 cents worth).

There are easy workarounds, though they are just that just that, workarounds, e.g., experiment with the Contour tool, it does a very good job of 'overcoming' this issue. Take for example a 700 x 700px donut shape or a 500 x 500px square (or any suitable shape using any dimensions), split the donut in half so it takes up 50% of the circle, duplicate it and flip it so you have two adjoining, perfectly pixel aligned shapes to make a complete donut or duplicate the square and snap it so it appears adjacent to the first square. In both instances you will see the hairline/gap issue. Make the shapes 2px smaller in width and height then add a 2px contour (with no stroke) to either. Result, overlapping vectors the same size as the original shapes but exhibiting no gap/hairlines on-screen or on export to any raster image format.

Is it the perfect solution, no, of course not but it's a viable option for now me thinks...

Thanks for the great response!

Hackintosh running Big Sur 11.2.3, Coffe Lake i3 with UHD630 graphics

MacBook (Early 2015) running macOS Mojave

iPad Pro 11-inch (1st generation) running iPadOS 13.5

Vista PC in the attic 

Link to comment
Share on other sites

I mean I must admit I was using these workarounds, like increasing the size, overlapping, or in some cases multi-layered overlapped divided extracted strokes to achieve an inside-stroke-look I wanted, I was extending images, where there was a "gap" I would duplicate the original shape, and center it and put it behind the two shapes, I was constantly doing so much for years now that I just felt enough compelled to write some feedback about it. It would be really, really nice to just not think about it. I agree I may sound to a technical engineer, a bit, arrogantly blonde.

Hackintosh running Big Sur 11.2.3, Coffe Lake i3 with UHD630 graphics

MacBook (Early 2015) running macOS Mojave

iPad Pro 11-inch (1st generation) running iPadOS 13.5

Vista PC in the attic 

Link to comment
Share on other sites

14 hours ago, BofG said:

@konstantnnn I can see your way of thinking, and you almost had me convinced of your way of seeing things. Then I started thinking about technically how it could be implemented (many (many) years ago I was a (not very good) programmer). As I started digging into things, I realised the key point that hasn't been addressed here - the layers have a stacking order. Your rectangles are visually next to each other but they are on a different plane (aka z-index).

See the attached document. Four non-pixel aligned rectangles, the top two are on different layers and so on a different plane to each other. The bottom two rectanges have been moved onto the same plane of existance by merging the curves and hence show no AA effect and they are stilll separate objects. Use the pixel view mode to see.

I don't have time to go into all the details of the why, but if you start moving away from a simple case of two rectangles and into more complex setups it quickly becomes an intractable problem. E.g. have a shape cross that boundary below one rectangle and above the other. Maybe that shape has a blend mode, maybe it has transparancy, maybe it's a compound with a different winding mode. It's a hard problem.

AA-planes.afdesign 1.35 MB · 6 downloads

Thank you for highlighting this. This actually may be added to my list of workarounds, merging curves.

Hackintosh running Big Sur 11.2.3, Coffe Lake i3 with UHD630 graphics

MacBook (Early 2015) running macOS Mojave

iPad Pro 11-inch (1st generation) running iPadOS 13.5

Vista PC in the attic 

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.