Are Affinity apps more capable on a Mac or Windows machine or about the same?

[Garth O]

I am trying to get use to a Macbook Pro after using a Windows machine for the past couple of decades. I know, I know. Anyway I am finding the changeover ok but a little difficult, so I am looking for some opinions. There is no doubt though, that I prefer Affinity over Adobe.

[R C-R]

No surprise but each platform has its strengths & weaknesses. Currently, there seems to be (marginally!) more bugs in the Windows apps. But for example there still seems to be some unresolved issues with the M-series silicon Macs, & probably more with hardware acceleration on the Windows version, although that also seems to affect only certain hardware.

As a Mac user, the one thing I can think of that I really think is an advantage for them is that the search field in the Help menu pops up menu commands that match the search text, so it is easy to find menu commands if you do not know or remember which menu they are on.

[walt.farrell]

3 minutes ago, R C-R said:

Currently, there seems to be (marginally!) more bugs in the Windows apps.

I have the opposite feeling from reading the forums, for whatever that's worth

In any case, I have the feeling that @Garth O (welcome to the forums, Garth!) might be asking about performance?

 

[R C-R]

4 minutes ago, walt.farrell said:

I have the opposite feeling from reading the forums, for whatever that's worth

I think the M-series silicon Macs are the ones that seem to have the majority of the complaints about Mac bugs, from slow first-launch times to crashes & so on.

As for performance, all I can say is it seems very good on my Intel Mac (specs below in my sig) but I don't know how that compares to an M-series model.

[v_kyr]

Capable in terms and the sense of what?

• Performance wise it highly depends on either platform/computer systems (Win/Mac) hardware equipment one has in use and thus from the equipped hardware components like CPU/GPU, RAM, SSD ..., their system software support, APIs/frameworks & drivers.
• Stability wise the latest OS system versions (Win 11, MacOS Monterey) with their security, API and framework changes, showed some new/recurring problems here in terms of overall hardware acceleration support (Win OpenCL, Mac Metal) and runtime environments like .Net on Win etc.

So all in all it's nearly 50/50 for both of the latest supported platforms here in terms of performance & stability! - Though usability wise and from own experiences, I give Mac platforms a slightly advantage here!

[NotMyFault]

On Mac, HW acceleration (GPU support) is a bit more robust with Metal for Affinity Photo. On Windows, there are more GPUs which could cause OpenCL issues (current high-end AMD GPU, all Intel integrated GPU, Nvidia Quattro GPU).

Both OS have a large cache of OS specific bugs.

Windows has a big plus regarding plugins like GMIC or still useful old google NIC collection which are unavailable on M1 based MacOS.

Apple M1 based systems deliver unbelievable good „snappiness“. On Windows, I experienced the opposite: much more periods of slowness on 3 different Windows systems.

Direct scan from Photo is unavailable on Windows. Direct Printing and Scanning as a can of worms on both OS (e.g. CMYK documents, margins).

To sum up: It is a matter of taste. Every OS has a loooong list of issues, none will make you totally happy. You can’t run away from these problems, you can only swap them against similar one with different smell and color.

Plugin-Support could be a deal breaker against MacOS.

A CPU with faster clock / better IPC is better than many cores with lower clock / lower IPC. Functions like Open / Save / HDR Merge use only 1 core.

Affinity does not utilize RAM >32 GB (but it may be useful for other Apps and OS functionality).

Use internal SSD only to store Affinity Documents (while working with them in Affinity). Internal SSD are absurdly expensive on MacOS. 

[NotMyFault]

Yes, at least i experience this. But I’m culprit of having attached a 14 TB spinning rust HDD, and all file operations (on SSD) now must wait until the HDD did spin-up - even if the relevant folders are on internal SSD.

Starting Photo or other Apps could take 15 seconds.

[thomaso]

6 hours ago, NotMyFault said:

now must wait until the HDD did spin-up - even if the relevant folders are on internal SSD.

Can't you prevent a HDD from spin-down?

If this system preference doesn't work maybe you need to reset SMC or remove a corrupt preference file or enter this setting via the terminal ...

sudo pmset -c spindown 0
it turns the hard drive spin down off
https://forums.macrumors.com/threads/disabling-hard-drive-auto-sleep.927961/

[NotMyFault]

Thanks for that hint, but i still prefer to use sleep mode to reduce wear, noise and power consumption.

The actual issue is that all OS (Win, Mac) seem to wake up HDDs unnecessary if you only want to access the internal SSD. If the HDD is on sleep (and still connected via USB, never disconnected) i can’t imagine a reason to spin it up (and wait for the HDD until running). No need to write anything, no need to read anything. And especially no need to show a spinning wheel (or no indication, but freeze the UI) until the disk is awake.

probably a side effect of default save / open UI which allows to change to a different drive.

[thomaso]

Ah, I misunderstood your intention – and I wonder if in macOS the more or less 'permanent' Spotlight + MRT processes may be involved in spinning-up a connected + launched HD. Have you tried to keep it connected but ejected? (with the disadvantage that you would have to launch the disk to access it if wanted)

https://lifehacker.com/use-this-terminal-command-to-force-eject-a-stubborn-dis-1849376498

https://www.addictivetips.com/mac-os/auto-eject-all-removable-disks-when-your-mac-goes-to-sleep/

[Pšenda]

18 hours ago, R C-R said:

As a Mac user, the one thing I can think of that I really think is an advantage for them is that the search field in the Help menu pops up menu commands that match the search text, so it is easy to find menu commands if you do not know or remember which menu they are on.

Just because you mention it, I've never used the built-in help, but always Googled the online version of Help. Not only because the built-in help can be several months old (uncorrected and incomplete), but when searching with Google, I don't even need to know in which application the function/term I'm looking for is.

[v_kyr]

2 hours ago, NotMyFault said:

Thanks for that hint, but i still prefer to use sleep mode to reduce wear, noise and power consumption. ...

You can try out if there is some possibility to finetune the wanted behavior via Amphetamine, see therfor ...

• Amphetamine ***
• Amphetamine Enhancer
• Amphetamine 101 (Amphetamine short doc)
• Getting Started With Triggers (Amphetamine doc)
• What is the Amphetamine App for Mac and Why You Should Use It
• Mac OSX Monterey External Hard Disks Going to Sleep ***
• External hard disks always put to sleep? ***
• ... etc.

[thomaso]

18 hours ago, R C-R said:

As a Mac user, the one thing I can think of that I really think is an advantage for them is that the search field in the Help menu pops up menu commands that match the search text, so it is easy to find menu commands if you do not know or remember which menu they are on.

... while the in-app help in macOS does not work if the language of the app is set to a language other than the system language. Then it can show only according menu entries but no help topic at all.

[R C-R]

37 minutes ago, Pšenda said:

Just because you mention it, I've never used the built-in help, but always Googled the online version of Help. Not only because the built-in help can be several months old (uncorrected and incomplete), but when searching with Google, I don't even need to know in which application the function/term I'm looking for is.

The benefit of using the search field in any of the Mac Affinity apps is that (like in the screenshot above by @thomaso) it displays not just a list of Menu items but also when the pointer hovers over it pops open the menu (& if needed sub-menu) when that item is located & puts a huge floating arrow next to it. This is not unique to the Affinity apps; it is a feature built into the macOS & works with any app that supports the help menu search function.

Not a big deal but still helpful when you can't remember which menu has an item you want to select (or just see the keyboard shortcut for if it has one).

[thomaso]

5 minutes ago, R C-R said:

Not a big deal but still helpful when you can't remember which menu has an item you want to select (or just see the keyboard shortcut for if it has one).

… while it does not help if the searched term is no menu entry …

… which can become additionally disappointing if then even the Online Help does not know the wanted keyword …

.

[R C-R]

2 minutes ago, thomaso said:

… while it does not help if the searched term is no menu entry …

I am not sure what you mean. Your Help menu screenshot shows the two matches for "lock" so that much is working as expected, but of course if there is no menu item that matches the search term, it won't show any. How could it?

So are you talking about the failure of the online help to find something that does not appear on any menu (like here the Lock Children item that appears only on the Context Toolbar with the Move Tool) or something else? If you want the search field to show context toolbar items, how could that work? There would be nothing to show in any other context.

[thomaso]

2 minutes ago, R C-R said:

If you want the search field to show context toolbar items, how could that work? There would be nothing to show in any other context.

I don't really expect the macOS help to show results for non-menu UI items. But if even Serif's Online Help does not find a term of their Affinity interface then one might appreciate if the macOS help would search within the interface, maybe Tooltips included, – not in menus only. However that would be technically achieved, it appears not impossible since the text in the interface is text, no pixel.

There are some posts of people not finding the Lock Children option or asking for the Lock in the Colours panel (indeed text as tooltip only).

I mention this in this thread only because you appeared to consider the macOS help as a reason to buy a Mac. I guess it's just fair to mention its limitations. too. I personally would never have expected that I can not use the in-app help if my system language is set different (… and that I can't find keywords of the interface in the Online Help, which probably affects both platforms).

[R C-R]

1 hour ago, thomaso said:

I mention this in this thread only because you appeared to consider the macOS help as a reason to buy a Mac.

No, I just mentioned that it was one area where it could be considered better than in Windows.

[v_kyr]

2 hours ago, thomaso said:

But if even Serif's Online Help does not find a term of their Affinity interface then one might appreciate if the macOS help would search within the interface, maybe Tooltips included, – not in menus only. However that would be technically achieved, it appears not impossible since the text in the interface is text, no pixel.

Apple Help books and what they offer don't work that dynamic interactive way, meaning here a help book can only find & show up what it's creator predefined and associated accordingly. So for tooltips and the like, if you don't explicitely define/document those and add the needed associated links & help text in a help book, there's nothing the Apple help system can magically find by it's own here! - To get an idea what the Apple help system offers at all and how it's help books are usually created, read through this older (never really updated) "Apple Help Programmers Guide".

2 hours ago, thomaso said:

There are some posts of people not finding the Lock Children option or asking for the Lock in the Colours panel (indeed text as tooltip only). ... ...

If it's not documented/defined/indexed (written down as described text & associated & linked) or correctly localized setup during the help book creation, how should that be found?

• lock chldren site:https://affinity.help/photo/

[thomaso]

29 minutes ago, v_kyr said:

Apple Help books and what they offer don't work that dynamic interactive way, meaning here a help book can only find & show up what it's creator predefined and associated accordingly. So for tooltips and the like, if you don't explicitely define/document those and add the needed associated links & help text in a help book, there's nothing the Apple help system can magically find by it's own here!

It's obvious that the Help doesn't work that way. I just tried to answer R C-R's question "how could that work?". Of course I agree if help contents or keywords are missing there is no reason to blame macOS but it is a lack of the app developers.

The fact that the Help gets rendered by macOS based on the contents inside the app package, for instance in /Applications/Affinity Publisher.app/Contents/Resources/AffinityPublisher.help makes me think that macOS could "easily" access other folders and files in the app package, at least theoretically. If macOS can look into this Help file it also could look into localization files which get used to render the interface according to the users choice. At least the expression "lock children" does exist within the Help.package and other files and thus the in-app help might possibly get enabled to point the user to "lock children" within the interface.

I assume Serif can also influence the language behaviour which currently prevents the help from displaying any topic if system & app language do not match. – Different to for instance MS Excel installed in German (it does not have an option to switch) where I can use English AND German search keywords and get for words existing in both also both help topic languages offered:

[R C-R]

1 hour ago, thomaso said:

The fact that the Help gets rendered by macOS based on the contents inside the app package, for instance in /Applications/Affinity Publisher.app/Contents/Resources/AffinityPublisher.help makes me think that macOS could "easily" access other folders and files in the app package, at least theoretically.

Have you considered that if it looked through all of this it would take forever to show everything relevant (& probably a lot of things that are marginally relevant at best)?

It has been a while since I checked the programmer's guide stuff about what to include in the keywords for the help topics but as I remember it they say something to the effect that it should be limited in various ways to keep searches reasonably fast & responsive (or something like that).

[v_kyr]

1 hour ago, thomaso said:

The fact that the Help gets rendered by macOS based on the contents inside the app package, for instance in /Applications/Affinity Publisher.app/Contents/Resources/AffinityPublisher.help makes me think that macOS could "easily" access other folders and files in the app package, at least theoretically. If macOS can look into this Help file it also could look into localization files which get used to render the interface according to the users choice. At least the expression "lock children" does exist within the Help.package and other files and thus the in-app help might possibly get enabled to point the user to "lock children" within the interface.

You have to look into the localized *.strings files, then you will recognize that those are just common app related map datastructure "key = value" pairs, and so are not help system related ones at all. These are just used for app UI localizations. - So for the english (default) localized one (Localizable.strings) you will see there ...

• "Lock Children [Select tool context toolbar]" = "Lock Children";  <--- (key = value)

And for the german localized one (Localizable.strings) you will see there ...

• "Lock Children [Select tool context toolbar]" = "Untergeordnete Elemente schützen";  <--- (key = value)

Further if you look instead into the English/EN-US help files, like for example "pictureFrames.html", you will see only a short description in the files for "lock children" ...

Quote

details open="open">
            <summary>To resize a picture frame without scaling its content:</summary>
            <p>Do one of the following before resize:</p>
            <ul>
                <li>Select the picture frame and then check <span class="ui">Lock Children</span> on the context toolbar.</li>

... and if you've setup just the Affinity apps to let's say -the english language- on an otherwise overall common german language setup MacOS system, then the Apple help system will still operate "german language" oriented and not in english (at least here actually under MacOS El Capitan). Thus searching here then after "lock children" wouldn't find anything meaningful at all. Searching instead after "Untergeordnete Elemente ..." may find some rare entries.

Searching then deeper on the APub related search field in the online help (no matter which localization is used) doesn't return anything here. - All in all the Apple help system under APub doesn't work well for El Capitan!

[thomaso]

1 hour ago, R C-R said:

if it looked through all of this it would take forever to show everything

Hardly. Just consider that almost all Affinity terms can be used already as search keywords without any delay. So why should a few more keywords influence the process time? Did you notice that the help does search + show results while you still type a keyword? For instance just the letter "c" shows results immediatley without any delay:

Or, for access to the entire help content, open the macOS help app (e.g. from APub by pressing 'cmd ?' or 'cmd shift ?' ) and enter the word "and" in the search field. To me, for the German "und", it displays 140 results immediately, while 112 results are from other apps than APub. That means macOS does search in the help files of other apps then of the current only. – Can you do a search which needs a noticeable time to show its results?

Also, as a comparison within APub, consider the speed of the Find & Replace function. Again I am not able do a text search which causes any delay in showing the "Find" results. Even just a single character like "i" in my current document shows a few hundred results immediately after pressing "Find", including the characters, respectively words, left & right of the searched "i".

1 hour ago, v_kyr said:

You have to look into the localized *.strings files, then you will recognize

My screenshot was just an example to test whether the in-app help contains "lock children" at all. Then the result of this search made me think of a theoretical possibility for the macOS help.app to access more than the currently limited contents. Again, actually the help should be improved by Serif, I don't mean the macOS help app shell get changed.

1 hour ago, v_kyr said:

german language setup MacOS system, then the Apple help system will still operate "german language" oriented and not in english

My screenshots from the Excel in-app help illustrate that it is technically possible AND realised to search & display several help languages synchroneously. This let me assume the limitation is not caused by the macOS help app but by Affinity, respectively the quality of their keywording.

It tried to switch the folder names of "de.lproj" and "English.lproj" within the .help package but it did not cause different search results. So I wonder if / how I could modify the "language.js" to make my APub to show results in both English AND in German. – Maybe you with your coding skills might know?

/Applications/Affinity Publisher.app/Contents/Resources/AffinityPublisher.help/Contents/Resources/resources/js/language.js

if (!String.prototype.startsWith) {
    String.prototype.startsWith = function(searchString, position){
      position = position || 0;
      return this.substr(position, searchString.length) === searchString;
  };
}

function setLanguage() {
    var language = navigator.language || navigator.userLanguage;
  var prefix;

  switch(true) {
    case language.startsWith("en-GB"):
      prefix = "English.lproj";
      break;
        case language.startsWith("en-gb"):
      prefix = "English.lproj";
      break;
    case language.startsWith("en-US"):
      prefix = "en-US.lproj";
      break;
        case language.startsWith("en-us"):
      prefix = "en-US.lproj";
      break;
    case language.startsWith("de"):
      prefix = "de.lproj";
      break;
    case language.startsWith("es"):
      prefix = "es.lproj";
      break;
    case language.startsWith("fr"):
      prefix = "fr.lproj";
      break;
    case language.startsWith("it"):
      prefix = "it.lproj";
      break;
    case language.startsWith("ja"):
      prefix = "ja.lproj";
      break;
    case language.startsWith("pt"):
      prefix = "pt-BR.lproj";
      break;
    case language.startsWith("ru"):
      prefix = "ru.lproj";
      break;
    case language.startsWith("zh"):
      prefix = "zh-Hans.lproj";
      break;
    default:
      prefix = "English.lproj";
      break;
  }

  if (window.location.replace) {
        window.location.replace(prefix + "/index.html");
    } else {
            window.location = prefix + "/index.html";
    }
}

setLanguage();

 

 

[R C-R]

2 hours ago, thomaso said:

Hardly. Just consider that almost all Affinity terms can be used already as search keywords without any delay.

That is because they intentionally limit the number of keywords. Just read through the developers stuff about this, It explains it much better than I ever could.

[thomaso]

2 hours ago, R C-R said:

That is because they intentionally limit the number of keywords. Just read through the developers stuff

I read the chapters "Search Concepts" and "Indexing" and did not notice any hint about limiting the number of keywords.

Do you seriously believe that some added keywords would increase the search time from 0 to X seconds? The article from 2003 (!) appears to me far less relevant than the practical experience we can have nowadays. Unless I don't notice any delay with a search in any help (or in APub's F&R) I do not see a reason to believe in your idea of "it would take forever".

Consider that today a search in the entire internet with billions of pages is done without delay and, additionally, is able for fuzzy search (which multiplies the number of your entered search keywords). I can't remember, but I suspect that search speed or technology wasn't that developed 20 years ago. Right now a google search for lock children reports "about 1,050,000,000 results in 0.56 seconds". – Would you really mind if a search in a macOS help would take 0.56 seconds for a fraction of this number of results, let's say of 1000?