ziplock9000

Yes it is strange. The algorithm itself for tracing will be fairly short in C/C++ code that will almost completely be platform agnostic as it's just manipulating data and not a lot of system specific APIs. This can with very minor (if any) tweaks be used inside the codebases for Windows, iPad and MacOS versions of Affinity Designer. If for some reason the mac versions are Objective-C, the conversion to/from C will be extremely minimal. I do this all of the time, it's less than a day's work for a single developer.

Ok I follow you now. Thanks Anyway to both of you. This is cleared up now. Thanks.

TGA is a very common raster format and it doesn't work. It forces me to save as afphoto when I click save, even with no changes. It doesn't work with the save dialog though. It forces me to save as afphoto when I click save, even with no changes.

I've just checked this with Photo 2.x (which I just upgraded to from 1.x) and it works as you've both said. I tried it with a TGA and when I hit save the only option is afphoto format? So I assume some formats do work, others don't? As a side note 99% of what I use is PNGs anyway, so this ain't an issue and essentially makes this now a very minor edge case.

I use the suite mostly for game development and in that there's often times where something like a PNG needs to be opened, very quickly edited and then saved in-place over the top. The whole process can often last <10 seconds with Photoshop and basically 99% of image editing tools over the last 30+ years. With Affinity Photo, this extremely quick process is doubled in duration or more due to having to export the image rather than just being able to click save without ANY thought. Because this process is something that can happen 1000's or more times during the production of a game, this extra red-tape becomes annoying VERY quickly to the point that this simple thing can (and does) force us to use other tools. Has V2.x fixed this issue or is there a workflow change workaround? PS. Again I would like to stress this extra step DOES make a huge difference to workflow and causes issues even if to someone who's use case does not need to make these small but extremely frequent changes can't perceive it.

As the title says. UPDATE: I meant right-click edit for file types other than .afxxxx like bmp, png, etc

So this was never actually properly implemented after 8 years?. If you hold ALT while moving a node (which you have to to move one side independently of the other), the snapping doesn't work. It only works if you move both nodes.

I'm having this exact same issue with 1.10.6.1655 I can't change the size of existing slices I can make new slices The slices are checked I can can the size and rotation of graphics even though I'm in Export Persona This has happened before, it's as if AD gets stuck in a certain mode, restarting does not always help. 3 years later and I'm guessing this will never get fixed now as V1 has will not get any further fixes. But what happened after the video was passed on back in 2020? @Sean P

Can you confirm any fixes for this will never come to version 1 of the software, even though hardware acceleration was actually part of that version?

I have a feeling Serif wont use another API that works just fine on AMD cards that competitors already use either. Remember, competing products work just fine. Serif have just chosen to use the API that has poor performance. Seemingly even with V2.x of the suite The issue is mostly with them not AMD who provide a valid, working API. Again, let me repeat: Competing products work fine.

That's grand and certainly in the right direction, but not confirmation of the situation with such a limited set of data points. For that we'd need a bigger data set and multiple combinations of graphics cards, driver and OS versions. A couple of data point is not 'confirmation' What ever problems AMD has had, the industry has found a way to work on their products just fine with GPU acceleration with a plethora of products from video editing, streaming and of course vector and bitmap design, while affinity notably hasn't. The problem is very much in Affinity's court when those other competing products work fine.

I see a theory not confirmation from minimal testing. That would come from lot more testing and comments from serif themselves. We've been fooled before. Even if it DID work, it should have worked in version 1 as it was part of the product features that were sold to us a long time ago now.

What's worse is they took away some features from V1.x of Designer and blamed the reason on other companies, just for the feature to magically come back for V2 of the product. I've been signing the praises of these products to a lot of people over the years, now I wont be.

So they have done the bait and switch and screwed over users of version 1 who have supported this product from the start. I thought it smelled fishy and didn't add up all of the excuses and blame they were putting on AMD Remember this is NOT a new feature, it was part of version 1. They have pulled it because they want to make it a selling point for v2. Serif, you've went from hero to zero with this terrible move.

It's more than just a nice to have really. Graphics apps have had this basic functionality for over 3 decades.