Lionel Seidman

@TonyB Thanks for the informative reply. If you do go down the multisampling route, you should be able to get pretty good quality anti-aliasing by using 8x multisampling (i.e. 64 samples per pixel) or higher. The downside there would be potentially slower performance during image exporting, but if the user wants high-quality exports I think they'll be willing to wait a couple of seconds. It would be nice to have that option, at least.

I understand that anti-aliasing is being applied as we convert vector data into raster data, but what I am saying is that the way in which the anti-aliasing is being applied is creating faulty output in which the background color is improperly bleeding through. Let's suppose we have a pixel that is exactly on the seam between two objects. One way to render that pixel would be to draw object number one using anti-aliasing (giving us a 50/50 mix of the object color and the background color) and then to draw object number two using anti-aliasing, giving us a 50/25/25 mix of objects 2, 1, and the background color. This appears to be the way Designer is doing things right now, and as you can see this gives us the wrong result! The final color for this pixel should be a 50/50 mix of the color in objects 1 and 2, with no weight given to the background color. It is definitely possible to achieve correct looking output in this situation, and we know that other programs are already doing so, such as Ai. What I am looking for is someone within the Designer team to address this concern to. If this is the wrong channel for that, I'd appreciate if someone could point me in the right direction.

I didn't mean to say that the geometry is of no concern to me in general, just that the geometry of the shapes looks fine, and that I am not concerned about it misbehaving. The only thing I am concerned about is the seams between pieces of geometry. If two pieces of geometry are exactly adjacent to each other, and when we rasterize the geometry we are able to see remnants of the background color showing through the seams, then I would say the program is misbehaving.

The geometry isn't really the concern here. The problem is the seam between one polygon and another. Ai handles these sorts of seams quite nicely, while Designer does not, so in that sense, Ai is more accurate.

@TonyB maybe you can weight in here. I am trying to speak with somebody on the Designer engineering team about the idea of fixing the underlying problem here once and for all, so we don't need to continue using these sorts of workarounds. I am quite sure that the problem can be solved, and I'd be happy to explain to somebody how to do it. Do you know who I might be able to speak to about this?

It looks like AI has solved the problem, so it must be possible, right?

Thanks for your feedback, guys. If I overlap the components, that does generally solve the problem. However, that is only a workaround and it doesn't solve the core of the problem which is that Designer is not handling adjacent non-overlapping objects correctly. The process of getting every object to overlap every other object it is adjacent to can also be very time-consuming, especially if you are opening complex files that were not created that way in the first place. As someone who is new to Designer, this feels like the one major flaw in it that I've come across so far. I think it would be really nice if Designer could be improved so we don't have to deal with this problem anymore, rather than just getting used to it and always coming up with workarounds for it. Is it possible to bring this thread to the attention of an engineer on the Designer team?

Hi there, This issue still seems to be present in Designer, both on screen as well as in the final output images, which is creating a major problem for me. Does anyone know if a solution has been developed for this problem yet? If not, I'd like to propose a couple of solutions that should address the issue: Solution 1: When the user is exporting an image, allow them to specify a level of multisampling (i.e. 1x, 2x, 4x, 8x, etc). For instance, selecting 2x would internally produce an image 4 times as large as the one specified by the user, and then downscale it before writing it to the file. 4x would internally produce an image 16 times as large. This is something us users can do manually ourselves, but it adds a bunch of extra steps, so it would be nice if it was a build in feature. The disadvantage of this approach is that it only reduces the appearance of the seams, but does not eliminate them. I’ve attached 2 images to demonstrate the level of improvement of using x4 multisampling. Solution 2: Have the program skip performing antialiasing on vector components entirely (bear with me) as it produces the output image, thus (presumably) eliminating the seams entirely. Then, as an alternate way to provide antialiasing, allow the user to specify a multisampling level (2x, 4x, 8x, etc) to use during the export process. This way a much larger image would again be produced internally, which would then be downscaled to the size the user requested before it gets written to disk. This should have the advantage of completely eliminating the seams discussed in this thread, while maintaining a decent level of antialiasing, which the user would control via the multisample level. I think Solution 2 is a much better way to go, if it's possible to do it that way. You might even be able to apply solution 2 in real time to eliminate seams while we use the application. If you have any questions about these ideas please let me know.