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

Search the Community

Showing results for tags 'afd-5525'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Affinity Support
    • News and Information
    • Frequently Asked Questions
    • Affinity Support & Questions
    • Feedback & Suggestions
  • Learn and Share
    • Tutorials (Serif and Customer Created Tutorials)
    • Share your work
    • Resources
  • Bug Reporting
    • V2 Bugs found on macOS
    • V2 Bugs found on Windows
    • V2 Bugs found on iPad
    • Reports of Bugs in Affinity Version 1 applications
  • Beta Software Forums
    • 2.4 New Features and Improvements
    • Other New Bugs and Issues in the Betas
    • Beta Software Program Members Area
    • [ARCHIVE] Reports from earlier Affinity betas

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Website URL


Location


Interests


Member Title

Found 2 results

  1. 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.
  2. Hi everyone. For some reason, moving even a single artboard around with a couple of shapes and text layers in it is pretty slow and lags a lot. My system specs are the following: Intel Core i9-9900K, AMD RX 580 8GB, 32GB RAM, NVMe SSD 512GB, running macOS Catalina 10.15.7 and Affinity 1.10.1. Metal acceleration is fully supported and I’m getting good numbers in all kind of benchmarks and other apps, but artboards in Affinity Designer seem to be very slow for me. Tried all settings, Metal, OpenGL, OpenGL (Basic). Metal seems to be the fastest out of all (as it should be I suppose), but still not acceptably fast. It feels like 5-10 fps which is strange to me. Situation shown on video became even worse when moving group of artboards. I should mention that any other actions I do in Affinity Designer are remarkably fast and smooth (after many years of using Adobe apps). Color corrections, transforms, vector tools all of these are just flying. But artboards... Here’s a quick screen recording I made. You can also see detailed CPU and GPU load during performing this operation. I’m also attaching project file. Appreciate your thoughts and opinions. Artboards.mov Performance Analysis.afdesign
×
×
  • 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.