Balakov

HSB gradient support is in. That should cover most freely available Photoshop gradients. If anyone desperately wants support for CMYK, Grayscale or Lab colour gradients, and they have an example .grd file they can send me, just let me know. The code isn't hard, but I don't have any examples to test against.

@ianrb I've just pushed a version that should support transparency. See how you get on with that! Gradients with complex transparency may be a bit fiddly to edit in Affinity because of the fake stops I add to carry the transparency info when there's no colour stop to attach it to. They should work fine as-is though. There will also be an inconsistency if you have a colour stop and a transparency stop at exactly the same location with different midpoints. At that point we've hit the limits of what you can do with Affinity gradients though, and it shouldn't be a very common occurrence. Next task, HSB gradient support!

I added partial support for transparency a while ago, but the trouble is that Adobe palettes support more complex transparencies than Affinity can cope with. Transparency stops are completely separate from the colour stops which allows for complex transparency gradients on simple colour gradients or vice versa. The converter supports transparency only when the transparency stops exactly match the colour stops, but looking at the screenshot you posted in the other forum, that's likely not going to help with that you need. I have a plan for sometime in the future to "fake" more complex transparencies by adding dummy colour stops. I just haven't got around to it yet.

Hi all. I've just posted my .grd to .afpalette converter too in the Resource section of the forum. Hopefully it may be of use!

I spent the last weekend creating a tool to convert Adobe suite .grd gradient files to .afpalette files for use in the Affinity suite. There are so many great resources for gradients out there but no easy way to get them into Affinity applications without a lot of manual labour. The tool is hosted on GitHub (the Javascript code is available for the curious), but all processing is done in your browser. No files are uploaded anywhere. https://mikestimpson.com/GrdToAfpalette/ There are a few limitation around colourspace (RGB only) and transparency (not supported), and I have not tested with a huge number of .grd files. It works for what I needed 🙂

Hi, I've just updated to Designer 1781 on Windows and my artboard backgrounds are now super bright. I run in dark mode with the artboard background grey level on the lower default setting, but it doesn't appear to have any effect. Moving the slider does nothing. I've attached screenshots of 2.1.0.1781 vs. 2.04. This was working fine in previous beta builds. Cheers, Mike. 2.1.0.1781 2.04

I've been having this issue for years dating back to Designer V1 and the same issue has remained in V2. My job is making .NET Windows software so I've done some performance captures during the slowdown which hopefully might give the developers a bit more insight. I don't work with very heavy scenes, my normal workflow is to create a few scratchpad artboards, drop some reference images and then use the pen and shape tools to make my designs. I'm generally not using any advanced features. The first perf capture is after about an hour or working. At this point clicking on objects is taking about 1 second to register and about the same time to switch tools. Memory use is around 3GB on a 32Gb machine (Designer is allowed 16GB in the settings). Dragging things around is very choppy. If I restart Designer everything comes back up to speed and memory usage drops to around 800MB. Not sure if that's relevant as the undo buffer won't be using any RAM on a fresh boot. The second attached image is the perf capture after a fresh boot with the same scene loaded. An interesting new symptom that has appeared in V2 is that the Designer process no longer exits properly when it's got into this slow state. I have to kill it with the Task Manager before I can launch it again. The application window is not visible, only the process still exists. The culprit in both cases seems to be Serif.Interop.Persona.DisposableResources.Find() which, in my naive interpretation sounds like a memory leak or cycle in the Garbage Collector. If I break the debugger while the process is trying to exit it never leaves that Find() method. Anyway, hope that helps. Happy do do any more testing as this happens pretty much every time I do any work in Designer.

If you start up a blank document, set the font to what you need and then go to Edit -> Defaults -> Save, then new documents should always default to that font. I got fed up with Arial being the default on my system!

Thanks for your reply, Pšenda. Would you be able to elaborate on how to define a gradient vertically? I'm looking at the gradient editor and I can't see a way to change the orientation. Cheers, Mike

Hi, I've got a set of gradients in an Application Palette and it's really hard to differentiate between them as they all run into each other (see attached image). Even with the view set to the largest thumbnail it requires quite a bit to concentration to pick the right one! I'm aware I could use "Show as list" to separate them out, but for my non-gradient palettes it's nice to see all the colours together and it's not possible to set a view type per-palette. It would be super if there was an option to display gradients vertically in the Swatches panel. Or just display them vertically all the time! I can't really see an advantage to seeing them horizontally. Cheers, Mike

Thanks Sean. I can confirm this is still happening in the new 1.9 release.

Hi, I normally run Affinity Designer with all snapping options enabled, and this is normally fine. However, I've been making some vector patterns today and noticed that having the "snap to gaps and sizes" option enabled absolutely kills the performance when there are lots of elements within an object. I've attached a Designer file of a simple dither pattern that turns out to be a pathological case for snapping. Make sure "Snap to gaps and sizes" is switched on - I run with everything except "Force Pixel Alignment" switched on. Moving the first shape about is absolutely fine. Moving the second shape around starts to get a bit juddery. Moving another shape after that (including going back to the first shape and moving that again) gets really laggy. After moving a fourth shape we're into 1 second+ update times and maxed out CPU on all cores and threads. I've had it take as long as 10 seconds to respond and Windows complaining about Affinity Designer not responding. I appreciate that I shouldn't really have the gaps and sizes snapping on in this scenario, but it took my a good while to realise that it was this option causing the slowdown. I don't even think about my snap settings most of the time, they normally just work fine. It's debatable if this is a bug or not, but it feels as though the snap candidate selection should probably give up after a certain time to preserve UI framerate. Snapping is a very interactive operation and relies on being able to see the snap candidates. When screen updates are over a second, snapping is essentially useless anyway. Cheers, Mike Snap Test Case.afdesign

This was one of my first thoughts, too. I dropped the undo limit to 250 a while ago but it made no difference.

Hi, I've been spending a lot of time in Affinity Designer recently and I've noticed the performance slowly degrading over time. It takes about an hour of use before I really start to notice the problems. Dragging objects around becomes juddery, some mouse clicks won't register instantly, and the CPU regularly spikes to 100% when performing operations. Relaunching Designer fixes the performance issues for another hour or so. I can normally tell when performance is going to tank by the amount of memory Designer is using. It starts at around 400MB and over an hour climbs to about 2GB while I work. After about 1.8GB things start to get noticeably bad. I've tried reducing the undo buffer size and messing with the RAM Usage Limit, but nothing seems to fix it. This may just be coincidental, though. I'm on a 32GB system and work with simple files that average about 40k so I should not be having memory issues. I can't say for sure when this started happening, but probably a few months ago. I've experienced this on my old PC (intel i5 with 16GB RAM and a GTX 1070) and my brand new AMD 5600X with 32GB and same the GTX 1070 (fresh Windows install and fresh Affinity Designer install). I've also tried both Designer 1.8.5.703 and the 1.9.0.927 beta with stock brushes/assets. It feels like some internal list is getting larger and larger over time and causing every operation to take longer. It doesn't seem to matter how complex the scene is. Once it's slow the only thing that will bring it back is a relaunch. If I can provide any more information or test anything out, please let me know. I'm normally in Designer for at least an hour every day so I see this issue all the time. In addition to the hardware mentioned above, I'm running the latest nVidia 460.89 "Studio" drivers and outputting to a 37" Dell ultrawide monitor running at 3840x1600. I've also got a Wacom tablet plugged in, but nothing exotic that I can think would affect Affinity. Cheers, Mike

Hi, I'm trying to use a Global Colour on the stroke of an object with multiple strokes and it's not working as expected. This is on Affinity Designer version 1.8.5.703. The repro is to create a single object with two strokes, create a global colour, then apply that colour to both of the strokes. If you edit the global colour it will only affect the last stroke that you applied the colour to. Re-applying the global colour to the stroke will "fix" that stroke, but then the other stroke will have lost its connection to the global colour. Cheers, Mike