SrPx

This solution is very similar to what was found out recently with a BMP of the 32 bits kind (the glitch was different: it wouldn't show anything, just a transparent canvas). It gets solved doing a similar trick to what you just mentioned. As it'd be something to do in general with transparency/32bit (although this tiff was saved in 8 bit) or transparency channel info, I don't know. But what I mean is that might not be just file format specific.

[ placeholder to say that I 100% agree with that, I'm just busy right now, will reply better tomorrow. And yep, happy new year ! 🍰🎈✨ ]

Edit: It also happens with Knife tool, but the 'copy as SVG' (preference) trick also works as a workaround. I got the shapebuilder and booleans problems just with basic Arial. I think it's all related, causing problems in both shape builder and booleans (EDIT: and Knife), some issue in the code converting text to curves, or something to fix by them in the text item itself. The other day I found a workaround consisting in, after converting to curves, and also maybe 'geometry->merge curves' depending on the case, setting then in Preferences/general-> clipboard "copy as SVG" (no need to restart the app). Then copying these curves (ctrl + c or right click "copy", I mean) that come from text, then click "paste special" in Edit menu (for the sake of speed, can assign a shortcut to Paste Special, I did so) , and then a dialog box that appears, choose "paste as Scalable Vector Graphics" (SVG). It generates a group, while you need to operate directly over curves, so, in the layers panel move the curves out of the group and delete the empty group. Or select the group, right click, ungroup (or just ctrl shift G with the group selected) , if you prefer so. I would warn not to delete the original curves too fast after doing the paste, as if the paste doesn't do it in-place, you can use snapping (on) to make it match perfectly with the original in position (if snapping settings are correctly configured) in a fraction of a second. This fixes it for me. Takes a few seconds (it takes way more time to explain it ). To at least doing what I want in the project, until this gets fixed. Is not long to do, and can even deactivate the preference setting on the fly after the fact, as it takes the change without restarting. Just checked now again (tho I had discovered it the other day), and yep it happens with any Arial text (I don't think it's happening only with some fonts...) converted to curves, and the trick seems to work for shapebuilder and booleans. One cool thing is that if you prefer to have all time "Clipboard: copy as SVG" preference off (ie, as the copy&paste "SVG style" thing might flatten some other features when copying, but not sure about it, it's just intuition), as needs no restart, can activate only for a moment (or a 4 hours session) when you need shapebuidler or booleans, then go to preferences again and change it back. Of course, it's a bug. It very much needs fixing. But I think the above is a "fast" and ok workaround, meanwhile.

Sorry to chime in. This doesn't collide/give a problem with having there a custom profile generated by a color calibration software, right? Like those generated (indeed, often, for those of us who calibrate the monitors every now and then) by software like iProfiler or Eizo's ColorNavigator, using them with a colorimeter (i1 display pro) to calibrate the screens. These apps will set a new profile with every calibration in various places of the system, this being one of them. I was wondering if Affinity needs solely a sRGB color profile there to operate fine, as this would be a problem (I have sRGB there, but also two other wider range custom profiles, all as "ICC" not "WCS".). Another question I have, maybe related... Is Photo doing the internal operations in sRGB? (Gimp and PSP do this, actually) I say it as I am basing my workflows (not photography, so no develop persona, neither RAWs) in Adobe RGB color profile. Surely is unrelated, but I noticed that the color panel (color studio), in the foreground and background color samples' circles, in v1.x was like using sRGB or something very similar, for files that actually were using Adobe RGB profile and had much richer color, so. Adobe RGB has much more intense greens (among other tones) that can't be reached in sRGB, which can be easily checked in a monitor capable of this range (ie, RGB color 0,255,0 on canvas will look very different to the foreground sample in color panel, being that also 0,255,0 RGB color, in V1 ). In files that are Adobe RGB, and being my default Affinity settings also Adobe RGB. But thankfully, version 2.0.3 is using apparently a wider range color profile in the color panel's foreground/background sample circles. I don't know if it's now (in V2) using Adobe RGB, or just my monitor color profile, but in v2 the color panel sample color circles make justice to the Eizo monitor's wide range, and there's no difference (or almost) between the circle sample in color panel, and the 100% color in the canvas (ie, filing a marquee with the tone). And so the color in the sample circle is identical or close to what is painted at 100% in the canvas, in V2. I have set Adobe RGB as my default color profile in both Photo versions. It makes me a little nervous to think stuff could be internally handled in sRGB. But I suppose that's not the case. Gimp and PSP do have problems and limitations due to using sRGB for all internal operations. I have Open CL disabled in v1 and v2, though (due to other reasons). Edit: I guess the problem is the "virtual" part, being there WCS, not actual ICC. Maybe it's not the sRGB thing, and just happens to be that this profile is the one only profile used in that particular system. If so, then having only the sRGB profile there would not be mandatory for Affinity to work well with color?

The integrated card can be an issue... maybe if the Affinity apps are not really designed for other thing than dedicated cards, or at least not so much. Also, for having much less capability, it all adds up. And many apps can crash if the VRAM (or shared memory in this case) is not enough. Blender is rock solid stable now, but till recently (don't know now, at the speed it evolves) it would crash if you tried to GPU render with Cycles a large scene that wouldn't fit in the VRAM memory. It would give you the feared red icon pop up window of 'insufficient memory', and usually not crash the entire app, but a crash (render lost), nontheless. Many other apps, too. That crashes are not happening with other software doesn't mean there can't be problems in an OS or drivers. I was of that idea, as am geeky too, and we tend to think we have our OS under control (not that this is really possible with Windows) to realize after a DISM and SFC run that I, like many in this forum (and in the world, surely), had some corrupted system files (in my case, they weren't the culprit of the problems, but I for sure don't want to have the system so). It's super common, as Windows is anything but clean handling certain things, and some software installers do a really bad job, and worse the uninstallers or Windows doing that. There's also power outages (even micro cuts), which without an UPS, make a corrupted file quite a possibility, etc... many ways in which a system file could get wrecked. So, I recommend always (if the person is tech savvy, you clearly seem so already in the first post) to run SFC and DISM. Yes, the other thing, hardware, is very rarely the case. But I wanted to rule out a messy RAM installation, or even having got a bad RAM chip (it happens more often than people think). If that's out of question, I'd say then is surely the most common in all what we've seen lately: The new update, until several iterations (typical situation in the beginning of a new software or some very heavy revamps in it) it's going to be very picky if the OS is not very pristine in everything (.NET, Windows Updates/Windows version, disk with no bad sectors, graphic card driver up to date, etc) . Often it is just that other apps are more "tolerant"; other times, that the other apps use less modern methods and tech, etc. So, I mean, that "but this and that work..." does not necessarily mean that it has to be Publisher (it of course can be...but a lot of people run it without crashes, so, research in your side is always convenient) : very often there's something in the user's system. Indeed, most of the times, even if it does not trigger other apps crashing or errors. The benefit I see in this complicated situation is that those of us that have applied this system "curation", end up with a much more stable system, which is a +1 overall for serious work. I would really recommend to upload the crash reports files (folder path to find them, I pasted it in some post above). I don't do it (so, what am I doing recommending it to others, hehe), but also I have no issues now, and the ones I had, I discovered workarounds myself (I shared them around here, tho). I mean, it's the safest bet if you want to get it solved. I like to fiddle and find my tricks and workflows, but I am weird in that sense. Being a crash that is hard to replicate, happens not very often (one of the reasons that make me think there's sth wrong in your system, hardware or -more likely- software/OS) , it makes it particularly hard to fix with a workflow (that is, not fix the bug, but find a workflow to avoid the bug, which all what my workarounds are, of course: they keep me working without issues until they release a bug-fix), and more of a case to send the crash report file to the devs, be it here attached to a post, or a dropbox they could set up for you ...Although...Monthly?, We are talking about version 2.0.3, right? Not v1.x... as 2.x has been around yet very little time. Happening so rarely ...+ using Affinity all day, and only twice a month happening makes it hard to address it as an app problem (and yet could be), as then it typically would happen constantly, and there at least would be "some" pattern, something that you do, that due to a bug, makes it crash. When there's none, it sounds a lot like a disk/file failure, some corrupted system file that's not called constantly, some system file conflict, some moment in which the memory is filled badly, some conflict with the graphic driver, etc, etc. The bad news is that there's no shortage of factors, in Windows. I don't either love the idea of the crash reports, but IMO your case would require the blood and tears I spent to find my tricks, or simply upload/attach such files, that's your decision. Still could be an Affinity bug, but I would personally want to discard any issue in my system, and definitely not just for Affinity apps to work well (indeed, for other more concerning aspects). But yeah, in these first moments there are many bugs, it could be one more. But really if we remove the factors in our side, better for us (for curating our system and to actually solving our problem) and for the devs (and actually we and them spending energy/time in what are actual apps' bugs ). I hope this can get solved for you. But yeah, the crash report is what would help to catch the bug, or them warning you about some problem in your system (like just some hours ago, one user that had issues with an intel card driver, and the crash report helped them see to that).

Do you have Windows updated to the last update ? .NET fine, and everything ? As it could be that... Also be sure to have the latest version for your graphic driver (uninstall it first, though!).

Sorry, I am curious, is there a specific need for 2700dpi ? BTW, IMO it's better to work with 2.0.3 than 2.0.

BTW, I don't understand why in Metadata panel in Affinity, RAW data shows it like if it were a Photoshop tiff. Metadata++ and ExifTool say it's a BMP version Windows V3, of 32 bit depth, but nothing about tiff.

BTW, the most obvious workflow (someone pointed sth out), if you happen to have purchased both versions, 1.x and 2.x... is open it in Photo 1.10.6, NOT saving as *.aphoto native extension (as somehow it looks great on 1.x, but opens as a transparent canvas on 2.x), export as PSD (I used "preserve edition" template, in "more" export options, and sampling as lanczos3 (does not affect here as I am not reducing, but just in case)) , and then such PSD opens correctly in 2.x. I had not yet tested that you can have both Photo versions open at the same time, but yep, you can. Surely not recommended if tight in memory, I guess.

I can confirm this: it happens. Does anyone know if 32 bits BMPs are supported? this is a 32 bits BMP, indeed, checked with an utility to read headers (one tag BMPVersion says Windows V3, and another Numcolors says UseBitDepth (if the 32 bits part is giving issues, then...), as two that caught my attention, the others are pretty normal, unless the PixelPerMeterX (and Y) which I believe are related to DPI, are somehow wrong... DPI file headers gave problems to a user recently in affinity, with a pair of PNGs, removing those problem solved. But I think I can't do it with BMP). If I open it in Photo 2.0.3, indeed a full transparent canvas is all I get. (Edit: And composition red, composition green, etc, in channels panel, seem to be empty). But... if I open it in certain other software (I just don't know if I can say the name here, direct competitor), I can save it as BMP 24 bits. The exported 24bit BMP file then does open in Photo 2.0.3 , showing a black image with some text ("el gato") and a logo, as expected I think, and like Irfanview opens it (which says it's a 32 bit image, btw). Another way to solve it, staying inside Photo 2.0.3, requires handling the channels window, as already said. It is having each channel (red, green, blue) info in the "background red, background green, background blue" channels (not in composition red, composition..). The grayscale info of each channel is there. Yep, I checked that right click->fill on 'background alpha' seems to restore the image. You can also right click on "background red" , create grayscale layer, creates a layer in the layers list, with supposedly the grayscale info of the red channel. And you can create masks also from those ("background red...), to affect only red , green or blue colors (but being aware of what layer you are on, and how you handle the layers. In all honesty, I don't know yet much about channels in Affinity (it is different to Adobe's, to which I was used to). Probably it's just some issue to fix to open well 32bits BMPs, that the devs can easily solve, no need to get into complex workflows.

A lot of problems seem to go away by deactivating hardware acceleration - Open CL. When you can't disable that in preferences, as it happens just in the splash, you can try to launch the app with a parameter that disables it :

Oki, glad then that you have now two workflows for this. Hopefully this will get a fix.

Yep, is logical to fear that. But from years around here... I think they fix all what they can fix. And they provide a lot more feedback about the issues than most software companies whose products I've used, or actually companies where I have worked at. Which is impressive, as with a small staff this is much harder. They are a very small company. No worries, I did not take it badly or anything.

Ok... Fully disregard the power of 2 thing. Unrelated. I don't know, maybe I dragged the slider too little to detect it'd happen anyway at powers of two dimensions as well. If I create a 2000x2000 px file in pixels, it works, but only if it's at 72 dpi. Tested restarting the app, in case it was something loaded yet on memory or something. If I set it as 300dpi, I get the problem again. Even if I start as 72dpi, 2000x2000 px, pixels unit, it works perfectly but if I then change in 'document properties' to 300 dpi, it will produce the error in the same figure that was working well 2 seconds ago. So, it's units in pixels but also dpi needing to be in 72 dpi. And apparently, nothing more than that (and the preference setting about use lines as points, of course).

Ok, I don't know what to think, now... NOW, files of 2000px x 2000px, 72 dpi are working well.... COuld be that it "remembers" the immediately recent situation, and that's why yet works well? (Edit: No, closed and restarted. It's not that) (using 2.0.3 oficial for all this)

Oh, I misread, then. Anyway, for me it does the issue despite being pixels, if the new file is not a 1024x1024, 2048x2048 (or whatever power of 2), even if is at 72 dpi, and pixels unit. If I drag the slider it goes crazy. Do you mean that if you create a new file, 2000x2000 px, 72dpi , in pixels, and with "use points for lines" unchecked, it works well for you? As it is producing the error here for those files... It's good to know that once you create the file, you can change later on to whatever the dimensions in document properties, and it still works well. Even after saving the file, closing and opening again, it still works well. So, a trick can be starting always as a 1024x1024, 72dpi, pixels, then change to the size you want in document properties. <--- Edit: NO. It does not.You need to work with pixels and 72 dpi for this not to happen.

Ok, rather interesting... It DOES work if setting the document to pixels unit in the "New " dialog, AND setting 72 dpi (with 300dpi it produces the error), AND, very important, is powers of 2, like with the graphic cards memory and all that. So, 1024x1024 (as Debraspicher has it in the screen) , 512x512, 2048x2048, 4096x4096, when setting new document so, and in pixels, and with 72 DPI, all those work without setting "lines as points", in preferences. With a new document of 2000x2000 px, 72 dpi, in pixels, it won't work, for example. Quite a clue (thanks to debra), but yeah...for the devs, not us.

@debraspicher Try now making a new (close other files, just in case) file at 300 dpi (default in Designer), not 72 dpi as I see in your screenshot... As at 72 dpi it works for me, too. It's DPI related, it seems. Edit: Probably you knew, and that's what you meant. Edit: Nope, is not that... it did look like it was working fine, to me...

It works flawlessly in my Windows 10. Unrelated (or maybe not), but I noticed a huge improvement (in browsing the list but also the app's startup) when ensuring Windows fonts folder is on my SSD disk, and not in the HDD. Specially as I have tons of fonts, free and purchased. Sometimes it can be a particular very heavy font (very complex), that maybe the app is processing as it lists the fonts. What settings do you have in preferences-> performance (is not only due to Open CL), User Interface and Tools, can share the screenshots? Other times is directly a faulty font... Getting rid of it solves the issue (there have been cases here with 1.x, if I recall well). (I would run SFC and DISM (command line Windows utilities), as affinity apps seem to be more sensitive to corrupt files, which for most users are never detected) And make sure it's not the graphic driver front (uninstall the driver well, install the newest driver for your card, restart, check then).

You can set "custom" windows scaling, in Windows Settings, which allows you to have an intermediate size, not as big as 125% scaling, neither as small as you see them at 100%. I found a problem though, at VERY specific custom scaling factors, Affinity apps (the three of them) do crash but only when double clicking the small circles of the foreground or background colors. Till date, I have only detected 110% (very commonly used) and 102% (extremely rare to used by anyone). 109% makes (my current scaling, all works great) all look identical to 110%, though. And you can set 111%, I tested it, it should not crash either. If I recall well, 115% works without provoking the crash in Affinity apps, and a user happily told me that 120% does perfectly the deal, too. You just need to know that the standard deploying menu-list is not the only way to set windows scaling on your system. I explain it better with screenshots, below. You need to click on Start icon (or hit windows key) , then on Settings ⚙️, then on System, then on Screen, and I hope the option (on the area at the right) in English is called "Advanced Scaling Settings". Click that link, and in a new screen you will type a number, instead of clicking from a dropping list. If I remember well, for all to take the changes, and really know if double clicking on the color selector (background or foreground) is going to crash, you really need to restart the system after changing the scaling. And so to check if the new fonts and other UI elements now do look more comfortable to you. Sorry, screens are in Spanish, but you will guess it due to the elements position. Edit: PLEASE, don't type 110! I was just making a screenshot in its day, that is one of the two numbers that make the Affinity apps crash, as I mentioned. I suspect there are more numbers causing the issue, but it's a minority, most scaling factors can be used safely.

Maybe I am assuming too much in saying that you don't have a dedicated graphics card solely from knowing your system is sharing memory for graphics... it could be having both! It'd be very dumb then from the laptop vendor to waste system memory in that case, but I would not be too surprised. RAM " has been upgraded". This... sometimes is not done the right way: The RAM brand/model, etc might not be fully compatible. Or a problem while setting the timings, etc. Or mixing chips (latency, etc), etc, etc. Here's hoping is nothing of that... Way less of a probability when installing anew a full 2x8 kit (two chips as a kit so to use ell dual channel memory, as is hugely important in AMD. Also assuming it's an AMD CPU, intel's graphic has its own special memory, if I remember well . When trying to reuse the 8GB you had, together with a new one... that can bring problems.

Yep, it would very helpful (Windows user here). Preferences -> Performance , Preferences -> tools , Preferences -> User interface screens, Preferences -> general. But the most useful thing is the crash report file (for devs. Link at the end of this post). You don't need to replicate again the crash, as it has been already generated, can post it as an attachment here (drag and drop the file from the folder, when creating a new post, over the light cyan-blue area at the end of the post where says "drag files here"). OP already mentioned the hardware acceleration- Open CL is off. That would have been my main suspect. Some crashes can be too for a corrupt file of the system, or a corrupt file project, or a linked file into it. Sometimes even a linked file's header that enters in conflict with Affinity (we've seen this, PNGs with certain headers, etc). About that, re-saving those linked files with any Affinity app, and re link again often solves the issue. About the case of there being corrupt system files, it is highly recommended to run the command line (in the Windows terminal/console) SFC and DISM commands (It's not a good idea to do it without instructions). https://answers.microsoft.com/en-us/windows/forum/all/sfc-scannow-and-dismexe-online-cleanup-image/db3b24de-a261-403e-9d11-8141d13f7954 https://support.microsoft.com/en-us/topic/use-the-system-file-checker-tool-to-repair-missing-or-corrupted-system-files-79aa86cb-ca52-166a-92a3-966e85d4094e Other apps are less sensitive, but with these apps Windows has to be totally up to date, and the graphic drivers, the newest ones for your card. You don't have a dedicated card, so it must be the mother board, the chipset drivers being installed and up to date. These are good measures in general to keep a pristine system, less tending to crashes, so, it's good overall, though. I understand that the system is using an APU or iGPU, integrated graphics in the CPU (as it's using shared memory). If it has only 0.5 or less RAM dedicated to the graphics, I would change in BIOS (you mentioned that it can't be changed. BIOS's access is denied? It wouldn't be surprising...I think there's a trick, though...) to set around 2GB. Would never do this in a 8GB system, of course, but you have 16. It's decreasing quite the memory for a 16gb one, but I'd totally do it if you don't count on a dedicated card (which, by far, highly recommended. A cheap 1650 is tons better than any current integrated APU or iGPU, for Affinity and many apps). If it is happening like twice a month it could be cases of memory for the graphics (working as "vram") getting filled only in certain rare occasions. I believe Open CL off does not mean that the graphics card or chip is doing nothing (unless you set WARP(render by software) in preferences, but that could be painfully slow). Being so rare the crashes, I would really dig if I can find a pattern in the specific files I am linking, or the type of files that they are. Or, if I can find any sort of pattern in what I did (like MikeTO suggested, as there's hardly a better way), even if haven't figured out any till the moment, I'd run mentally what I did, sometimes stuff escape a first thought. Specially as you normally are not getting the crashes. Although an unstable system or installation can behave randomly like that, too. It's useful to know the RAM (in Windows Settings-> System-> "About". Both the allocated and reserved, it tells it you there. The CPU (in some rare cases the CPU is extremely weak, while doing very complex projects). And the operating system and version (found as well in that Windows Settings, About area). The link for how to find (to attach here in a post or etc) the crash reports in Windows :

You are welcome!

This a sentiment I kind of perceive from others when a temporary fix is found. I truly believe it can't ever be the case: They want the app to work well. And more importantly, something like this is a symptom of a problem (with other ramifications, etc) : I have no doubt that they are looking into it, but they're having an extremely busy month, despite being holidays. The workarounds are only for professionals (and hobbyists, but the former might have a lot of pressure...I do know...) to save the day and/or the project, and allowing to keep using the apps in the projects.

@Realm_SGG I discovered that it does not crash when deactivating "show as list" in the brush panel. The bug will still be there, but it won't bother you, you can use these brushes. Indeed, Photoshop used to list the brushes so in the brush panel. I made a video about it (excuse the Spanish): bristles.mp4