EVH1

It's an Intuos 2 Model XD-0608-U. Starting with the latest driver at the time and working backward, it took me some time to find one that would support it and open from the Control Panel. Up to this point, It has been able to control the functionality in the 2D and 3D apps I use with it. So far, my other applications haven't crashed in the same way.

Hi @Stokerg, My tablet is an old Wacom with driver 6.2.0w5 -- the only driver I found that works for me in Win10. Designer's input method is set to low precision. I don't recall changing any preference defaults, as everything seemed to be working initially long ago with my very brief testing back then (Designer v1.6.5). I am just beginning extensive usage of it, having bought it in advance of the upcoming needs which are upon me now. I could be uncovering an issue that was always there. Thanks for the help.

Unfortunately when I recorded the behavior today, it took quite a bit longer to trigger the issue than it did yesterday, but what I've attached here still provides a chance to see it occur. I found this happens more rapidly -- seconds, not minutes -- with larger pencil Widths and Pressure readings active. One normally wouldn't do what I'm doing here. It was only my simple way of trying to identify why the Designer keeps freezing during normal usage for me. This is just an attempt to accelerate that process. I can't guarantee I'm not uncovering another way to make the Designer freeze, but the developers will know. In many cases, sluggishness varies on different hardware with differing amounts of available CPU cycles. Sometimes sources of it are interrelated by design or code, so I hope the investigation helps them in some way. Within the attached movie, the Designer starts lagging at around 3 minutes. At around 4 minutes, the application freezes. You are correct Wil JF, freezing doesn't mean code isn't executing within an application. It simply means the UI has stopped being responsive, and from all apparent feedback, nothing is happening. I did not spend any time debugging the process at the instruction level and I don't have the time unfortunately. If the UI is in its own thread as it should be, and I believe it is as the application has over a 100 threads, it should still respond unless it is waiting for another thread or result that isn't operating as expected in order to continue with cursor movement. I didn't see that, so that might be a clue. I was still drawing when the pencil cursor freezes in the attached movie. Anytime this has happened and I've shifted focus to another process and returned, the Designer stayed frozen. I have waited a long time to see if the Designer would recover. When I shift the focus away from the application, then return and click on it, Windows will report the application is not responding and the operating system displays its hourglass cursor. The OS itself is responsive, so the freeze is confined to the Designer. Since I have released the pen immediately after the freeze in the past, I know I did not build up a large amount of additional instructions for it to process. It did not recover in any of the lengthy times I have waited. Hopefully the QA team can reproduce this and it helps find the trouble. (Note: I clipped the waiting period from the end of the video and cropped the right side) AffinityDesignerFreeze.mov

Hi Serif QA, I just updated Designer to v1.10.5 and I'm having a frequent troubles with application stability. I've narrowed the scenario down as much as I could. To attempt to see the sluggishness issue from scratch, try the following: open Designer, create a new document, choose pencil, set stroke to 20, controller to Pressure, then just start drawing continual zig-zag patterns extremely rapidly without lifting the draw button (or stylus pen tip). Keep that going very quickly and eventually some internal queue within Designer -- perhaps the input queue, the undo queue, the render engine, or something else -- will begin to reach a point at which it starts to lose the ability to keep up. The onset of the sluggishness can sometimes be sped up by releasing the mouse (or pen) during the rapid zig-zag strokes for a split second, then continuing. The goal is to restart rapid drawing while it is still trying to finish drawing the control handles for the splines. Try this technique or a combination of the two if you weren't able to see it using the first method. Depending on your performance settings, it may take more or less time for it to occur. I've seen it take many minutes; other times it has happened fairly quickly. When Designer reaches the point of sluggishness, it may freeze entirely if the user attempts to stop and start drawing again, as it does each time on my system. Changing/disabling the various combinations of undo levels/rendering settings I have tried has had no appreciable effect so far, including disabling hardware acceleration. I updated the GPU driver, Windows 10, and Designer versions recently. I haven't done extensive testing where undo is at the minimum. Hopefully this will allow you to see what happens. Running a profiler in the IDE should help show where the application is spending the majority of its time when this is occurring. This may be the source of many of the sluggish behaviors reported, even though some appear to involve dragging or snapping. Sometimes these issues happen when C++ applications continually create and copy any array that needs to expand to accommodate new, rapidly changing data. Software development convention from an industry leader says that an array that needs to be expanded should be doubled in size with each copy, but you actually never want to do that. It becomes extremely expensive to perform data structure resizing (creation+data copy) at large sizes, and that threshold is reached fairly quickly. You can potentially leave nearly 1/2 the machine's available memory unused unless you are manually reducing the expansion amount by what memory actually remains. Instead, the best practice is to expand each array, or whatever data structure you are using, by a fixed chunk amount. Using a profiler, you can test what value works best. If the additional space added to your data structure is too small, you'll end up needing to perform a copy too frequently. If it is too large, you'll consume too much of the available memory and it will take too much time. If it is far too large, and the remaining memory is the chunk size minus 1 bit, the application could crash, fail to do so if an exception is caught but not handled, or leave that memory on the table unless you reduce it in that scenario. If that's not the trouble, it could be the render engine needs a bit more optimization or different data structure choices are needed -- those that don't resize with every added piece of data. My Designer freeze typically happens right as I lift the pen or mouse button, when the spline control points are drawn. I know Designer doesn't have nearly the data or rendering demand I put my machine through nearly daily, so I'm convinced you'll find the source of the problem, whatever it is. Wish you the best.

As a first time user I eventually deduced what was happening, but I thought that by default wherever I initially clicked would be the region filled, whether that was inside the loop, the parent shape, the line itself, or outside the border. I wasn’t able to figure out how to force it to fill the loop in addition to the base form, so I’ll try your suggestion. Thank you.

Draw an enclosed vector shape with an inward facing self-intersecting loop somewhere along that curve and then attempt to fill that loop, Designer will always attempt to fill the larger shape instead.