chessboard

I would like to bring this up again. Double tap to Undo and/or Icons for Undo/Redo and Delete in the toolbar would really help and would be appropriate for a pen and touch device like a Surface. At the moment a keyboard is still needed when using Affinity on a Surface. That's counterproductive for a mobile device.

@stokerg thanks for the link! I tested the MSI/EXE install and I must say, that AD now feels so much snappier! I didn't test long (just 10 minutes for now, because of other things to do), but my first impression is, that the MSI-Version runs much more smoothly (even with OpenGL turned on). At the moment I can't see almost any delay between clicking an object on the canvas or in the layers palette and the object being highlighted. Even without real lagging, the MSIX-Version felt much stolid. I hope that this impression will be confirmed as I continue to work.

Hi @stokerg, my processor is an Intel i7-11370H in a Surface Laptop Studio. I turned off OpenCL now, but for the next days I don't have jobs to do in AD. I was testing yesterday for ca. 15 minutes and didn't see any lags. But when I turned in on again, there where no lags either, even with the documents that caused them before. Just selecting and moving objects around doesn't seem to produce lags, even with large documents. Sadly I am to busy at the moment to test further. Edit: I see, 2.0.4. is out! I will check this and stop testing 2.0.3.

Hi @stokerg , I would like to jump in here because I have exactly the same problem with AD V2.0.3. The problem that AD starts to become extremely slow is not dependent on specific files in my experience. It happens with very simple documents as well as with more complex ones. Unfortunately, I can't contribute actual files, as all my projects are custom work and subject to secrecy. These delays affect all areas of AD in my experience, but especially the selection of objects, whether on the canvas or in the Layers palette, but also painting, adjusting colours, applying effects and more. Some actions take seconds to be done. Strangely enough, other actions show no lags again. The lagging can occur instantly when starting to work with a document. In other cases it can take some time to see the lags. I suspect it may have something to do with the nesting of the objects. For example, painting on pixel layers often goes more smoothly when they are on the top level of the hierarchy. If the pixel layer is subordinate to other objects, delays are more likely to occur. The same is for selecting objects. But there is no strict rule to that. When I work with the same documents in Affinity Designer V1, I don't see these lags. Something crucial must have changed between the versions. Can this possibly affect the memory management?

Exact the same here. I gave Designer and Publisher a few chances, but now that I have to finish my projects, I can't do any more experiments, so I did the whole layout again in Illustrator and Photoshop. At least it was pleasingly easy to export from the Affinity programs. I think the idea behind the Affinity apps is still great (and I will surely come back), but that doesn't help, if the apps aren't absolutely reliable. I very much hope that a lot will improve in the foreseeable future.

To be fair: If the option "show lines in points" is enabled, you can still enter the value in millimeters in the input field for the line width, if you add the unit "mm" to the numerical value. It's just that you can no longer read the value in millimeters, but only in points. However, it is no problem to set a line to a line width of, for example, 10mm. I just realized that I have never changed the units in the fields to mm in version 1, but have always worked with pt.

I would like to suggest the following small change to the Layer Palette UI: The hierarchy lines on the left side should not be displayed in gray but in the darker selection color. This would make the layer staggering easier to read and the whole thing more logical.

I think this message is a mistake. According to this list below Version 2.0.3 has not been released yet:

2.0.3 is a beta version. You can find the infos about what has changed in the beta section of this forum. For AP for Windows it's here: However, you have to look up each individual beta version of 2.0.3 to see what has changed there. There is usually no list of all changes since 2.0.0, which will only be available when 2.0.3 is released.

If you have more than one GPU you could also switch them in the Affinity preference pannels in the "performance tab". Isn't this the same as the setting in the Windows preferences for the apps? I suppose the brush lag must have to do with either AMD CPUs or AMD GPUs. On my old machine I have both (AMD CPU+GPU) and there only turning off OpenGl helps. On my new Machine there is an Intel CPU + nVidia GPU. Here I don't see brush lagging, no matter if OpenGL ist turned on or off. But beyond that, the freeze problem (as seen in the screen capture video on page 1 of this thread still exists. But it is very difficult to narrow down the problem, because there is no pattern when the freezing occurs. For me it doesn't seem to have anything to do with the pure mass of content in a file. Rather using a lot of clipping, layer effects like gaussian blur seems to be of importance. I also see some strange glitches in the rendering when moving objects. The disapear instantly but while dragging the objects there can sometimes some strange pixel forms be seen. Therefore, I suspect that the problems might have something to do with the rendering. Obviously Serif has changed the rendering engine a lot, which in turn could be related to the GPUs.

Ok, sorry then for the repetition. Was too lazy to search first.

Comming from an other discussion I would suggest to implement a separation preview at least in Designer and/or Publisher. With this preview you should be able to check all separation plates, including overprinting and see if there are any spotcolours.

Now, this works. But would you say, that it is logical to need two times the same colour (i.e. the same CMYK percentages) to have it one time with overprint and another time not overprinting? Say you want to have magenta to be not overprinting in general, but one shape with the colour magenta should overprint (a yellow shape to get a nice red). Therefore you need to set up a second mangenta colour with overprinting turned on. Mm 🤔, not sure if this is really a logic workflow, because after all it's still the same ink and still ends up on the same color separation. I would say, that overprinting is rather shape based and should be adjusted for shapes, because it determines if a shape is part of a specific separation plate or not. This is something that can be found throughout the Affinity programs - breaking with traditional workflows for... - well, what for? Just to be different?

@Tia Lapis Right. TIFF can save lossles or lossy and handle layers (However, I'm not sure if this is part of the official specification of this format, or a propriety feature.) But as mentioned above, lossy is a no-go, because it damages the quality of the image if it is used serveral times in a row. But back to the problem with large files: The filesize on the disk is one side (rather less important today). The question is, can the image software handle this large images when they are opened and edited. This seems to be the problem that @JaGold appearently had to struggle with in AP V2.

Well, of course 😉. You never want to lose quality, especially in the manufacturing phase. If the client agrees, maybe you can save the final version in a lossy format, but even that publishers don't like to see. Saving in a lossy format, reopening the file, and repeatedly saving in a lossy format means that sooner or later this file will become garbage. BTW, I don't know any lossy file format, that could handle layers. You might want to add that Photoshop is not very good at compressing the file. Other programs can do that better. In Photoshop, for example, it is already decisive whether the bottom layer is a "real" background layer. If it is, this also saves some memory. For whatever reason.