rvst

It will be slower for sure because the dns client will have to wait for a timeout on it's name resolution of the affinity update server's canonical dns name.

I use Comodo firewall in custom ruleset mode. This means that literally every single connection attempt from any software on my system (even the OS itself) pops up an authorize dialog from the firewall unless I authorize the application permanently (obviously, this isn't something most users would do, since a wrong choice could block a system application - I use it precisely because certain apps phone home gratuitously and I tend to block network communication for those apps if I think the vendor is collecting too much telemetry). So I just turn off that permanent authorization and then every time Affinity attempts to make an outgoing connection, it pops up the authorize dialog box.

I can't duplicate this. The outer glow looks identical on the file I export. What app are you using (Photo / Designer?). Could you post a copy of the file, or at least a subset of it that we can use replicate your problem?

It'll convert the exported file to use whatever colorspace / ICC profile you select in the export dialog. If you're not exporting in sRGB, then you need to click the checkbox to embed the profile, otherwise there'll be an assumption it's sRGB and if it's not, then it will display incorrectly. But if you're exporting as sRGB, even if you're not embedding the ICC profile, it should display correctly. So the question arises whether you're sure you're actually working in the sRGB colour space or not. I also could not duplicate this problem.

I just checked this and my Affinity Photo V2 only connects at startup, not when opening a file or changing persona. My account is logged in.

I'm also one of those who uses bicubic exclusively. A simple option on the preferences to configure the default resampling method would be nice. It would reduce the number of mouse clicks on each export while preserving the default of bilinear if the user doesn't change it.

Yeah - the example I gave was a little contrived, just to illustrate that there are some tools that can't be used in a non-destructive workflow even with an embedded RAW file.

Your system could nonetheless benefit from a current gen PCIe 4.0 nvme SSD (which I imagine your X470 board supports). They are several times faster than your SSD. My Samsung 980 Pro gets 7,000MB/s of sequential read speed and around 5,000MB/s sequential write (writes slows down a bit after the turbo write cache has been filled, but even the slowest is still several times faster than 770MB/s). Considering that the files we work with in Affinity are pretty large, such a speed up in read and write speed would be quite noticeable and contribute to a much snappier feeling system.

There are a number of tools that don't work in that way. Those would be the ones on the toolbar on the left. The adjustments and filters can work non-destructively on the embedded raw layer. So it's a nice enhancement, but only a partial solution. When using a tool that works on a pixel layer, the assistant will auto-rasterize the raw layer. At that point, it destructively applies those develop settings. So you'll have to throw away the edits on the pixel layer if you need to go back and change the develop settings, after which you'll have to rasterize again to a new pixel layer and reapply the edits. An example: you output to a raw layer, make a couple of adjustments with say curves and white balance. Since they don't operate on a pixel layer, when you go back into the develop persona and change the develop settings then revert to the pixel persona, the image will reflect both the new develop setting as well as the adjustments you made with the curves and white balance. But let's say you want to remove a blemish. You select the inpainting brush, copy the raw layer and either rasterize it yourself or let the assistant do it for you. At this point, the develop settings get destructively applied to the pixel layer, which now hides the raw layer. You remove the blemish with the inpainting brush. If you want to go back to alter the develop settings on the underlying raw layer, first you have to hide or delete that rasterized pixel layer (otherwise you'll be changing develop settings on the pixel layer instead of the raw layer). Then you alter the develop settings and go back to pixel persona. You'll see the updated raw layer, but the second you unhide that blemish removal layer, it in turn hides what you did on the raw layer as it's a snapshot of an older raw layer. That said, there are a lot of adjustments and filters, so multi-file enhanced-workflow functionality like we're talking about in this thread would be a huge leap forward even if it only works with adjustments and filters and not with the tools that operate on pixel layers only. It'll still need a metadata catalog in order to implement it though, but not necessarily a file format change I think

Could you post a screenshot of the Advanced Security Settings for C:\Program Files\WindowsApps\SerifEuropeLtd.AffinityPhoto2_2.0.0.1640_x64__3cqzy0nppv2rt\App\Photo.exe? Right-click, choose properties, click the Security tab, then click Advanced.

This is the reason I still use Lightroom in my workflow and Photo as an external editor for the stuff I can't do in Lightroom. UI-wise, it shouldn't even be that hard to do. Develop Persona needs a file-explorer-like window to display thumbnails of multiple files, then a couple of options to copy and paste settings and assign a rating to the file and a sort capability to only show files with a certain rating (or above) and an option to batch export the selected files. Making some assumptions here, I suspect that the hard part would be that this type of functionality would require a catalogue with metadata, something that Affinity does not have at the moment. Unlike the UI pieces, it's non-trivial functionality as there are plenty of potential issues such as catalogue data integrity. Also, that Affinity (as far as I understand it) doesn't have or use a RAW-type file format in the .aphoto file might be a significant hindrance to this type of workflow. Consider that some of the Affinity functionality only works on a pixel layer, so even if you output a RAW file from the Develop Persona, tools such as the inpainting brush still need to work on a pixel layer. So you go remove a blemish on a portrait, the Assistant rasterizes the RAW layer, and then you no longer have a RAW layer. If you turn off the auto-rasterize option, you'd still have to duplicate the RAW layer and rasterize it to use the inpainting brush, so going back and modifying the develop settings for the RAW layer won't do much because the pixel layer that's now on top of it has had the original settings already destructively applied. Only if all of the adjustments, filters and tools could work non-destructively on a RAW layer instead of some needing to work on a pixel layer would it be seamless. So it may require Affinity to completely rework some code or alter the .aphoto file format or a combination of the two. Hard to tell without knowing about the internals. What seems relatively simple on the face of it could be a pretty big development undertaking

Nice analysis, although I think you need to be careful about drawing too emphatic a conclusion about the cause if you based it only on the low resolution performance tab of task monitor. If I use OCCT and look at the CPU/GPU load during the benchmark, the CPU is for sure near 100% for a good part of the test, but there's a portion where the load drops right down just as the load on the GPU spikes up Aren't OpenCL kernels compiled at runtime on the target device and not the CPU? Your point about whether or not it matters is very well made. Benchmark workloads are a total mismatch to typical workloads.

That's the error one would get if you try to directly invoke the program from C:\Program Files\WindowsApps\SerifEuropeLtd.AffinityPhoto2_2.0.0.1640_x64__3cqzy0nppv2rt\App\Photo.exe" When invoked from the start menu icon created during the installation process, a special security context is set that allows the app to execute (by matching a conditional ACL expression that assigns Read/Execute and otherwise falls back to Read only if the context is not set properly) Invoked any other way, you'll get this error message. You should not. You should have read access only for the folder "C:\Program Files\WindowsApps\SerifEuropeLtd.AffinityPhoto2_2.0.0.1640_x64__3cqzy0nppv2rt\App\" but not the folder above it. It should be owned by SYSTEM. If it looks any different, you (or an application) probably tried to take ownership of the WindowsApps folder hierarchy, which will break things. So, can you confirm that you're trying to launch the application by clicking on the unmodified icon for the application in the start menu that was placed there by the Affinity installer? If you are and you still get this problem, then something might be wrong with the ownership and permissions in ""C:\Program Files\WindowsApps"

GPU-Z isn't the greatest tool to see load over time. OCCT allows you to graph pretty much any of the sensor data it monitors. This is its graph of my GPU clock while running the benchmark tool. There are two big spikes in use that last for about 4 to 5 seconds each, so its definitely loading the GPU (caveat - this is on an Nvidia card, not a Radeon, but that isn't really relevant, as the point of this comment is to state that the benchmark is offloading to the GPU for a period of about 8 - 10 seconds in my case)

It's a private company, majority owned by the two principals of Serif. You can't buy the shares

I was curious to know the answer to this question, so I did some testing with both Windows Performance Toolkit and the benchmark feature of Affinity Photo. Let's answer the first question: Q.) do any of the methods launch faster or are they equivalent. A.) they're equivalent. This shows sequential alternating launches of the MSIX installation by clicking the icon in the Start Menu and then a direct invocation of Photo.exe in an unzipped version. I waited with my mouse in the top right corner and closed the process down just as the UI became usable. The graph shows each process's CPU resource usage by time, with time on the X axis. Now the second question. Q.) Do the different methods result in different application performance. A.) It appears there is a difference in GPU-related performance on my machine at least. Single GPU raster operations look like they take about a 20% hit when running in the sandbox. I benchmarked three different methods of invoking Photo. The first was launching the MSIX installed version from the Start Menu (ie., in the sandbox), the second was launching the MSIX installed version directly from the executable installed in C:\Program Files\WindowsApps after having added execution rights to allow direct invocation (ie., outside the sandbox). The third was launching the application directly from the file hierarchy created by unzipping the MSIX installation archive (obviously also outside the sandbox). I did two sets of benchmark runs for each method and during each run, I did multiple benchmarks to get the results averaged out. Pretty much everything is equivalent across all three methods, except for that GPU performance in the sandbox noted above. With the app versions, note that it's the exact same executable, running from the exact same location on the same machine, just invoked differently (start menu vs double click the actual executable having assigned appropriate execute permissions to the Users group). So the one is running in the sandbox, the other isn't. Machine spec: CPU: AMD Ryzen 5950x, using PBO and a negative voltage offset. Best core can hit 5,125 Mhz Motherboard: Asus ROG Crosshair VIII Dark Hero RAM: 128GB GPU: Gigabyte Auros Master RTX 3070 System disk: 2TB Samsung 980 Pro nvme

A resizable base address register is a setting that pertains to the PCIe bus. It allows a PCIe device, usually your graphics card, to negotiate the size of the base address register which is normally 256MB. You can read some info about what it does here: https://www.techarp.com/computer/guide-smart-access-memory/ This article has info on how to enable it for Nvidia and contains other useful information about the feature: https://www.nvidia.com/en-us/geforce/news/geforce-rtx-30-series-resizable-bar-support/ and this is another article with similar info: https://hardwaresfera.com/en/articulos/resizable-bar/ AMD calls it "Smart Access Memory". It doesn't appear at a glance that your CPU supports it. However, there appears to be support for some platforms that aren't "officially" supported, but hard to tell whether your combination of hardware supports it (CPU + RX580)

Yes, but it isn't relevant to this issue, which is that a slider has been hard capped to an arbitrary number instead of setting the range "0 - InstalledRAM". Typically, I would set this slider to a certain percentage less than the available physical RAM And it's not just the wired memory than can't be swapped out - there's also the working set for each process. If there's not enough physical RAM to contain the full working set of a process, then thrashing will occur.

This is an interesting performance-related point that a lot of people aren't aware of. If you use a Samsung SSD, then their Samsung Magician software can reserve space so that this doesn't happen. If you don't have a Samsung SSD, you can manually prevent this happening by shrinking your main partition and leaving 10% of the SSD as unallocated space at the end of the disk

I'm a kernel-level software engineer R-C-R. I know how OS memory management works thanks .

It wouldn't crash the computer - it would just swap, slowing things down. But be that as it may, it's a bit silly to have a limit like this for no good reason other than the slider doesn't set a dynamic range

In V1 of Affinity, I was able to override the RAM Usage Limit (or at least I think it was overridden) to a value larger than the slider range by manually typing a value into the field. I believe this static range was subsequently fixed, although I'm not certain of that In V2, that no longer works. It resets to 65536 MB. Yet I have 128GB in my machine. So why is this slider range not being set to 0 - "Maximum Physical RAM"? I frequently have all three products open simultaneously with several files loaded in each one. It would be nice if Affinity products could actually exploit all of the RAM I have.

Thanks, compound masks are a neat feature, although in this case drawing on the normal mask seems to be possible only to mask out additional areas not already masked by the live mask. I wasn't able to edit the areas already masked out by the luminosity mask to selectively remove the mask in some places Choosing "Edit mask" instantly crashed my Photo V2

Yes, technically you're correct that they're separate technologies that don't require concomitant usage. I have a tendency to conflate them in my own mind as being in that group of "failed things that Microsoft has tried unsuccessfully to impose on users", since they're both comparatively recent technologies introduced by Microsoft that users loathe.

Ah, perhaps he is. I just saw a very recent post of his where he replied with a screenshot done on a Mac and thus made an assumption I'm not talking about Affinity's interface at all as it pertains to that remark. I'm instead referring to how Windows skins the desktop shell so that even the Start menu now has these huge tiles and most of the system apps have been moved to the app sandbox. Many of us replace the horrendous Windows 10 Start menu with an alternative one. Personally, I use Stardock. There are numerous complaints and bug reports in the various threads on integration with other software. This is surely "difficulty communicating with other apps which are not sandboxed", right? Indeed, if implemented properly. But it wasn't implemented properly and so it is preventing communication in some cases. This sandboxed architecture introduces more points of failure. It might reduce installation issues somewhat (although not convincingly so from the many installation errors others have reported here), but it does so at the cost of increased integration problems. Partial control. And a read of the many rants in the forum threads highlights that this doesn't work for a significant number of users This may well just be down to our different usage styles. Without making any assumptions about your own usage style, I'm a software engineer, and so my systems are high-end, heavily customised and optimised and I write a lot of scripts to do repetitive tasks. I use Windows Professional and the Group Policy Editor to tweak a lot of the functionality of Windows and also disable the Windows App Store, as do other users of Affinity as some have noted here. I value a desktop system where I have the control and I can tweak things and set them up as I please rather than submitting to the software publisher's idea of how I should do things. I have sufficient knowledge and skill to secure my system myself without needing to submit to Microsoft's sandbox (I always run only as a standard user and not as an Administrator) Perhaps a good illustration of this is to note also that I'm an Android user and not an iPhone user for exactly this reason. It gives me the ability to customise my interface and tweak many things, whereas the iPhone is a lot more prescriptive about how things look and are done. On Android, I can literally replace the entire interface with a custom one, which I do - I'm a Nova Launcher person.