Jump to content
You must now use your email address to sign in [click for more info] ×

Mans Lidbeck

New Members
  • Posts

    3
  • Joined

  • Last visited

Everything posted by Mans Lidbeck

  1. Thank you for this tip Komatös! I will try it the next time it crashes without the process dying. Best regards, /Mans
  2. Hi! Thanks and hats-off for the super-quick feedback Chris! My crash-reports folder does contain several .dmp-files, 2 of which are dated today, but they do not appear related to these crashes/lock-ups. I just produced a few new crashes but no new .dmp-files show up in that folder. New findings/summary: The problem also occurs in a single-monitor scenario with just two views open with at least one undocked. Quick-mask-mode works without any problem. It's only as soon as the marching ants come into play that it triggers. With OpenCL disabled, sometimes selection is possible without actually crashing but the UI becomes so unresponsive and stuttering that any further selection with ie freehand-tool becomes unfeasible until the second view is closed. I tried per your suggestion with a small 8-bit RGBA document with a single pixel-layer, but the problem exists even there, though it does take longer before crashing/slowing down. On crashing, one or more of the following happen: AF stops responding to input, gets a milky white overlay and Windows places the "(not responding)" in the title-bar. Once in a while, the application title-bar blinks as if recovered but then immediately returns to "(not responding)". This is basically the loop it gets stuck in until the app-process is killed via Task Manager. Occasionally, AF crashes silently back to desktop after a few moments in the loop described above. On very rare occasions it's possible to close the second view and then AF seems to recover. Most of the time, this is not possible since the UI has stopped responding. What tool would I need to produce a screen recording? Best regards, Mans.
  3. Hey everyone! I have recurring and consistent crashes in AF (1.9.2.1035) under the following scenario: Working with any selection-tool involving "marching ants"-selection while having a second view opened on a different monitor. More details: These crashes occur with or without GPU-acceleration enabled and seem easily reproducible. In my workflow, I use a small Wacom Cintiq tablet for selection and masking. To rule out the Cintiq from the equation, I unplugged it and placed the secondary view on another non-primary monitor. The crashing behavior remains the same. Typically, AF crashes within seconds from beginning an operation involving marching-ants selection. On the rare occasions where it is still possible to entirely close the secondary view, AF appears to recover. In most cases, however, it crashes to the point that I must forcibly terminate AF from the OS. Hardware configuration is nothing exotic - an Intel Core i7 rig with 16gb RAM and an Nvidia RTX-2080 Super GPU with all drivers up-to-date. Has any of you experienced this? Do you know of any work-around? Thanks a bunch in advance and have a great day! Regards, Mans.
×
×
  • Create New...

Important Information

Terms of Use | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.