User_783649

Turn off Show Snapping Candidates in your snapping settings here:

Consider the fact that you may have any version you like as long as you want, and no one will stop you from having access to your apps once you stopped to pay them (looking at you, Adobe). Just this thing alone is the reason I'm sticked with Serif. And I will be happy to pay once again for any major release in the feature, if I find new features and improvements are worthing it. Even if Serif decide to raise their prices at some point, I'd still support this decision. Because, for what these wonderful apps can do, $50 is just nothing.

From your screenshot, I can see that file you're working with is only 851x315px. And zoom level is 1747%. It's expected for any raster image editing program to see pixelation at such zoom levels. Did you started your .afphoto file with that resolution or was it resized via Document - Resize? Also, let us know – if it is a final exported jpg you opened on your screenshot, or an actual Affinity .afphoto file is loaded here? I'm asking this because you've mentioned that Affinity Photo file is around 300mb in size. It leaves us hope that there's still high resolution data in it. If you didn't rasterize all those images (linked or embedded) you can just try to resize your .afphoto back to higher resolution via Document - Resize.

Bicubic resampling is a good, universal resampling method and definitely should be made a default choice (or at least an option) in Affinity Photo. While we may found it in export window, next to more advanced Lanczos options, it seems logical to include it on a canvas level, in View Quality settings. Also it would be great to see it being added as an option in Designer and Publisher as well for the sake of consistency. As of now, in all three apps, we're limited to use Bilinear which doesn't provide the same level of visual quality and details precision especially while zooming in and out, resizing objects.

I think it would be better if you repeat your export in Affinity Photo with Bicubic option being selected. As I already mentioned it seems like you've done it with Bilinear which is default. And unfortunately, this option makes everything a bit blurry and lacking the details. I'm pretty much sure you'll be completely satisfied with the quality of Bicubic algorithm.

It's nice we have resampling options to choose from in Affinity Photo. However, we should understand the difference between them so we can use them on purpose. I made another test. You can repeat it by yourself. test_original.jpg (4.9mb) Original image. Open it and export with 1000px height, jpg, 50% quality, bilinear, bicubic or lanczos. test_1000h_bilinear_50q.jpg (172kb) Obviously, it blurs image a little bit and some details are being lost. Probably good to use in app, for canvas performance reasons, but totally not suitable for exports. Most likely, that @Danel used exactly this (default!) option, so that might probably explain why the result was not on par with other software. test_1000h_bicubic_50q.jpg (204kb) Seems like an optimal option in most cases. Not blurry and not over sharpened. test_1000h_l3s_50q.jpg (217kb) A bit more sharpness and details than in Bicubic. Might be a good choice when some extra sharpness is needed. test_1000h_l3n_50q.jpg (260kb) Very aggressive sharpening. Expected for this type of Lanczos. Final thoughts: It would be better for Serif to change the default resampling method in Affinity Photo export interface to Bicubic.

Very obvious and noticeable difference in sharpness for me between these pictures. Overall quality and sharpness is better on the right side. Especially parts with hat fibers and chair mesh material. However, it looks like some amount of output sharpening was applied to image on the right. Looks like a bit too much sharpening. Image on the left definitely looks more compressed to me, and lacks of details. Again, it would be useful if @Danel could tell us how the export from Faststone was made exactly? Are any extra-settings or options were involved?

After three years, in 2021, there's still the same problem with lack of proper antialiasing in Mesh Warp Tool. It doesn't matter if Bilinear or Bicubic method is chosen, seems like there's no antialiasing being applied at all (especially on the edges). Lack of proper antialiasing makes it almost impossible to use Mesh Warp Tool to create and adjust any kind of high-quality, realistic mockups in Affinity Photo.

I made benchmark file for anyone who can be interested in measuring Affinity apps canvas performance with text layers. There are multiple groups of text layers each of them containing from 4 to 72 thousands of characters. To start testing, select any group you like and start dragging it around the canvas. If you're seeing good visual response from your system (in ideal it should be something around 60fps) then you may choose another group with more text. You can also select multiple groups of the same or different size. At some point you should start noticing significant performance decrease, delayed redrawing and fps drop. My observations: For some reason, all these drag operations are performed solely by CPU. GPU is not used at all (see that tiny blue line in screenshots below). This fact may explain the reason why performance is so bad with dragging text layers and any artboards or group of objects with text layers. I measured system load and recorded CPU and GPU activity (see the screenshots attached below). System was tested with i9-9900K fully enabled – 8 cores and 16 threads. And I also tested it with only 4 cores and 4 threads enabled, without Hyper-Threading. Visual response was nearly the same (low) in both cases which is quite surprising to me. Seems like no matter how many cores you may have, it will stutter and lag without proper help of GPU. Verdict: There's definitely a need for more intense usage of GPU in such operations like dragging and moving layers on canvas. P.S.: Also added diagnostics file about procedure calling stack (might be useful for developers). affinity_text_benchmark.afdesign resource_diag_during_text_layer_move.txt

@MEB Seems like you have a bit more stutters with your iGPU. Thanks for the video, appreciate it! It's very helpful. The most interesting thing to me is that ALL performance problems are gone once I remove all text layers. After that I can literally move hundreds of artboards without any delays. Please see, how responsive are all of them. Yep, canvas still shows some visible tiles, but overall visual response is much much faster. So I'm wondering. Why text is causing this slowdowns? Maybe there's a chance you could pass this to the team? So they can discuss if anything can be improved with handling of text layers. Because, in every other aspect your apps are just perfect to me. Really love the whole suite! canvas_test_3.mov

@MEB Seems like this option (use only iGPU) has no visible effect on performance for me. Btw, my system is not a Mac, but a hackintosh. But it shouldn't matter I believe, as all other apps I mentioned above are performing really good on my system. I'm still wondering if it could be a general AMD Performance problem mentioned by some of your developer (please see the link above)? I also recorded a video of me trying to drag some of the artboards from my test file. Could you please check it once again and confirm that your system handle these artboards better? Thank you very much in advance! canvas_test.mov

Hi @MEB Thank you very much for your prompt and detailed response and time looking into some of my test files. It's definitely very interesting, especially the fact that you're seeing less glitches and lag even with your integrated Intel graphics (as far as I know Intel Mac mini's don't have discrete gpus). The most strange thing to me is that all other apps I'm intensively using including Photoshop, Pixelmator, Resolve and even Cinema4D are performing pretty smoothly and quick. I never seen anything like those glitches and lags I'm facing in Affinity suite. So sad, because I so much in love with your apps! Also, all benchmarks I run (Geekbench Compute/Metal, GFXBench, LuxMark and, of course, Affinity Photo benhcmark) are all show pretty good, expected numbers. So it doesn't seem like a problematic or damaged card/chip to me. I'm wondering if these issues I'm describing could be related to general AMD Hardware Acceleration problems discussed in this topic:

I talked with some of the forum members and asked them to run my test files I posted in one of my threads. Some of the responses were quite surprising for me as some of these people didn't experienced any lags or delays I've described in my posts. It all leads me to conclusion that my AMD Radeon RX 580 8GB card may be not powerful enough to handle Affinity apps at a proper screen refresh rate. And while my general questions from top post still remain open to Serif team, I'd also like to ask you about the following. If AMD RX 580 can be considered as at least decent GPU for Affinity? I know your policy about not recommending any hardware but... Is AMD RX 580 a really weak GPU for your apps? Just want to understand if it's my fault with weak hardware or not. Then I'll start to think about an upgrade maybe.

Thank you very much @R C-R I'm definitely starting to think now that my RX 580 maybe not powerful enough to properly handle Affinity apps at a good screen refresh rate. Maybe I need an upgrade.

Hi @R C-R That's actually very interesting! I see that you have Radeon Pro 5700 in your iMac. It seems like it's much more powerful video card than mine Radeon RX 580. Anyway, I'd very appreciate if you could look and test some of my files I've shared in this thread: I'm especially asking you to try open these: https://forum.affinity.serif.com/applications/core/interface/file/attachment.php?id=200314 https://forum.affinity.serif.com/applications/core/interface/file/attachment.php?id=200318 Please let me know if all artboards are moving equally smooth for you in the first file. And both text layers from second link are also moving equally smooth on your screen in the second file. Thank you in advance!

@Patrick Connor @Andy Somerfield @Mark Ingram @MattP Dear gentlemen, I highly respect Serif and simply want the very best for you and your products. Would appreciate a lot if someone from you could share some thoughts on this topic. Thank you very much in advance.

Hello @Kaffeepause Thank you for spotlighting these core performance problems of Affinity apps once again. I'm facing all these issues you're describing. It all was there on Catalina, Big Sur and now in Monterey. Affinity suite v1.10.1, v1.10.4. Unfortunately, there are lots of performance problems in Affinity apps, especially with text layers. However, after looking at your videos, I should mention, that in Publisher canvas refreshing algorithm works slightly different than in Photo or Designer. There's a kind of delayed response, so objects you're moving are being updated only after you stop moving your mouse. So Publisher doesn't continuously update selected objects coords but only in the end of your cursor movement. Similar behaviour could be found in Adobe's InDesign app, but it also offer you a setting to switch screen performance between Immediate Redrawing and Delayed. As far as I know, there's no similar setting in Affinity Publisher.

To Serif team. May we please know, in the end of 2021, why canvas rendering algorithms are still so terrible in all Affinity apps? 
It's just not pleasant to see at all. Lots of glitches, fps drops, screen tearing, jumping objects and visible tiling/blocky artefacts during any changes being made. While searching here on forums, I found lots of topics covering all these issues.
 Some of them are five or six years old. But some of these topics are much more recent. Various configurations, pretty good CPUs and GPUs of all sorts.
 But same screen tearing, artefacts and visible tiles. For a such long period of time. And there are still no fixes for that. In some of those topics I've found official responses, that "this is done by design", "it's the way our apps render the canvas".
 Well, it's not a good design then. And certainly not a good way to render the canvas. How you, at Serif, find it acceptable? Are you ok with seeing canvas rendering like that in your apps? How it passes QA and being shipped to your customers? Why there are headlines on Affinity website: "fast and glorious", "pan and zoom at 60fps", "handle 1000s of objects with no lag", "optimized for documents of any complexity"? When it is simply not true, but rather false statements. At least it is not true as long, as such core performance problems still persist for so many people, including myself. Why not consider implementing something like v-sync in your canvas rendering pipeline? Or something else that will prevent visible artefacts appearing during canvas updates. So it will wait for all the tiles to finish calculating their image data and then the whole visible part of the canvas will be composited and painted in a single (at least on the visible to user level) draw event. It will significantly reduce overall performance? Well, maybe, but then you'll need to find a solution for this as well.
 Now it looks like the best idea for you was to throw all these tiles at your customer's screen as fast as possible. Because who notice that mess? They'll be fine with that. But I do notice that. And I want to avoid any screen tearing and tile artefacts in my experience with apps even on the most basic and simple tasks.
So, where is mine "smooth and glorious 60fps experience"? I'm not even starting doing any serious graphic design work because I don't like your canvas in its current state. Sorry. Second, why mouse polling rate plays such significant role in your apps canvas performance? Recently I discovered this myself, and it was confirmed with your team members, that reducing mouse polling rate to default 125Hz significantly improves screen canvas performance. Significantly, but still not perfect yet. So why not restrict any user input events and sync them with dispay refresh rate / gpu redraw cycle? Just an example. The latest Safari has new option in their Debug menu: "Prefer Page Rendering Updates near 60fps". It ignores the display's refresh rate and throttle all in-window paint events down to commonly safe and achievable 60fps. So why not consider something like this and limit overall fps and user input event processing for the sake of overall performance improvement? Maybe then we'll get a better canvas? My main question is: is it an absolutely impossible to seamlessly refresh the canvas without all these tiles flickering around constantly once anything is changed in the viewport? I'm just wondering why it is still being considered as normal in Affinity apps to have a canvas behaving this way? Sorry if my post seems to be a rant or offended you in some way. I had no intent of doing that. 
I'm really wondering if Affinity suite can be made better for all of us. Or we shouldn't expect anything better being done in this direction. Maybe it's really a one big "pain in the a.s" problem for any software developers to make CPU and GPU properly talk to each other? 
Maybe there are lots of problems with major OS developers ditching OpenGL and moving towards Metal/DirectX? Also, we've seen this recent Apple's movement from separate CPU and GPU with dedicated memory to SoC solutions with unified, shared memory.
 Yes, I can understand that your apps should greatly benefit from that. Obviously, lower latencies, less memory copy operations, overall faster access to data.
 All things being done in one place. But... But at the same time I feel that it's just wrong to keep telling anyone on Twitter how good and fast your apps perform on those recent Apple SoCs, while its canvas (which is the main working and the most important area) lags and glitches in general for anyone with more traditional system configuration, even on the most simple scenarios like moving an artboard or a single layer around. I couldn't be the one who notices that. And my system is pretty powerful and it's clear that it deserves better performance and smoother visual response. What I see now is simply unacceptable for me. To be completely honest, I must say that I love your apps. Overall, they are much, much better for me than anything I've seen in this field. There are so many great features and innovative decisions, little details, that make it truly great.
 Every time I discovered these in your apps I was so excited and happy, because I remembered how bad the same thing was in Adobe's products. I remember lots of annoying, terrible things that made me leave Adobe's universe once and forever.
 Vast majority of these things remain unchanged for many years. Because they don't care about their software and customers at all. I found your company and your products to be a complete opposite. Small and passionated company with people really interested in their products. 
I don't want to be disappointed with you guys. I believe in you. I believe in Serif. Just can't stand this canvas tiles flickering and tearing. Sorry.

Sorry, seems my issue is duplicate of this: and this: Please, feel free to delete my topic. Sorry for spam.

Hi @SPaceBar Thank you for a quick response! I'm on macOS Monterey 12.0.1. Just did an upgrade recently. Do you think it might be a Monterey thing? Because I don't remember this happening for me in Catalina and Big Sur as well. We need someone else with 1.10.4 and Monterey to see if they can reproduce the issue.

Just discovered this little issue with Color Picker UI being showed with approx. 1s delay after click. Be it called from Context Toolbar or Character Panel or somewhere in Layer Effects – Color Picker always shows up with that delay now. Seems to be introduced in 1.10.4 (Designer, Photo and Publisher are affected) as I never noticed this before. It was always just as instant as any other UI controls. The only barely noticeable and subtle delay that I ever experienced, was switching between Personas in Affinity Publisher. But I can completely understand this as the whole UI needs to be rearranged. But Color Picker alone...

Let me start by saying that I absolutely love this wonderful feature in Affinity apps: to be able to filter typefaces according to how I organize them in Font Book by collections. However, there's a little bug. Here's what I discovered. In Character panel, when "All Fonts" option is active (by default), every typeface in the list shows up with correct number of fonts in the family. Once any other collection from Font Book, available in that list, is selected, every typeface now shows with two times more fonts. Every weight is being duplicated in the list. So I have two Regular, two Italic, two Bold and etc. I believe there's something with (re)sorting/(re)appending items to lists/arrays and it's just a very small cosmetic issue. But anyway, it would be great to see this fixed, as the feature itself, it is really great and very helpful. Bug persists across all three apps. Versions 1.10.1 and 1.10.4 on macOS Catalina, Big Sur and Monterey.

@MattyWS It's very inspiring to see such enthusiasm! I personally have nothing against Linux and would gladly support Serif on this platform even if prices will be higher. More to say, I have a couple of Linux machines at home and these systems are simply wonderful and stable. Distributions are improving and becoming better and better. Just maybe my views are a bit more pragmatic when it comes for estimating business expenses and analyzing the risks. We should understand, that: But anyway, bringing Affinity suite to Linux would be very great.

@Bryan Rieger Agree, I've seen that short demo on MAX. That's an interesting pivotal moment for them. Collaboration is really a new big thing. So we can expect Creative Cloud to become completely cloud-only service at some point. Piracy will be completely eliminated as well as term "software download". And then they will basically own every bit of you. Apps, your files, your activity and etc. Stop paying once - you lose it all. You own nothing. That's the future they want for us.

If Serif would start a crowdfunding campaign to collect $500k-$1m in order to launch Linux versions – would you support it? As I already mentioned above, I do personally see crowdfunding campaign as the best way for Serif to "test the waters" and see if there's any potential interest from Linux users at all.