Windows 8.1 Intel Celeron N2830 2.16 Ghz 4.00 GB RAM 64-bit Operating System 64 bit program VisTablet VT Realm Graphic Pen Tablet Tablet Driver: 2014_windows_vistablet_V5.05.exe / atwtusb.exe I get lots of "Not responding" for short periods when doing ANYTHING in the program. Note the program uses 100% of my memory (with all other programs closed). I can create new file, use brush with mouse or touch pad no problem. First attempt at using tablet pen, I hover over window and cursor changes from brush circle cursor to a windows "resize" cursor and stays that way everywhere I hover it. Upon touching tablet to simulate left-click, program freezes a bit, then after 5 seconds crashes to desktop. Second attempt, tried using pen tablet to click "File", nothing happens, cursor changes to "resize" cursor, and then again crashes to desktop. Third attempt, wiggle the pen over the window. Nothing happens. Wait awhile, then move it over menu bar, over color picker, etc. Cursor does not change. No crash. Then I right click (with pen side button) and it changes to resize cursor then crashes to desktop. Reproducible: Always Steps to Reproduce: 1. Hover over window with tablet pen 2. Touch pen to tablet OR perform side-button input 3. Crash occurs within 15 seconds or less Actual Results: As described in description Expected Results: Perform a left-click operation in the program and not crash to desktop.
Confirmed, this is happening.
That must have something to do with the tablet type or driver. I suspect that it sends way more events than other brands of tablet do or something like that. Unfortunately, we only have wacom, yiynova and huion test hardware (and a really old and obsolete genius tablet that tells the system it's a keyboard...) It's also pretty strange if this started happening with 2.9.7 because we didn't change _anything_ to the input code...
(In reply to Rafael from comment #1) > Confirmed, this is happening. Rafael are you able to report your RAM? Would be nice to discover if this problem is the VisTablet brand all by itself causing issues, or the combination of low RAM and VisTablet. I just bought a Microsoft Surface Pro 3 and tried Krita on that with no problem, but thats an entirely different brand/hardware/driver set. Both have 4GB of Ram however, and the Surface Pro 3 does NOT have the slow-downs or temporary "not responding" when dragging the window. Making me further suspicious of my laptop's configuration rather than VisTablet alone.
(In reply to Serafin from comment #3) > (In reply to Rafael from comment #1) > > Confirmed, this is happening. > > Rafael are you able to report your RAM? Would be nice to discover if this > problem is the VisTablet brand all by itself causing issues, or the > combination of low RAM and VisTablet. I just bought a Microsoft Surface Pro > 3 and tried Krita on that with no problem, but thats an entirely different > brand/hardware/driver set. Both have 4GB of Ram however, and the Surface Pro > 3 does NOT have the slow-downs or temporary "not responding" when dragging > the window. Making me further suspicious of my laptop's configuration rather > than VisTablet alone. i have 8GB of Ram. The problem is certainly with the driver, mine is atwtusb v5.05 too.
Hi, Serafin and Rafael! The bug is surely somewhere in the driver, so I guess the only real solution would be to fing a newer/fixed version of the driver. Although you can try to provide us a bit more information about what is happening there by following this manual and generating a log of what happens there: http://nonaynever.ru/kwiki/krita/BugWritingGuidelines#Tablet-related_Bug I cannot promise we will be able to solve the problem after that, but at least we will have some insight.
I am having this exact same issue with my Adesso CyberTablet Z8, even with the latest drivers and even though it worked fine in the 2.8 versions of Krita. I suspect that this has to do with the tablet likely being old (it came with ArtRage 2.6, even though the latest version is ArtRage 4), and I could always just go back to an older version of Krita, but I really want to try the new animation tools, so is there any chance that Krita 3.0 or later could support this tablet type better in the future? If not, which other tablets work best with the program?
Created attachment 96054 [details] Log file of the crash by DebugView Okay, this bug is still in version 2.9.9.1, i did as Dmitry said and i am attaching the Log file of the crash. There is, aparently, an important line where the error occurs and krita closes: "Fatal Error: Accessed global static 'KisPart *s_instance()' after destruction. Defined at C:\dev\desktop32\p\calligra\krita\ui\KisPart.cpp:189" Please, see the full Log at the Log file, hope it helps you to fix it, is being bad not be able to use the new versions of krita, i don't have another tablet and there is no new version of the driver. Sorry for the response delay, i hope this is still being seeing by the devs and there is no need to write another bug report.
Well, in Krita 3.0 the tablet code is rewritten once again. In 2.8 we used Qt's code, but that didn't support a whole bunch of tablets. In 2.9, we had our own code on Windows and X11, but the variety of hardware out there is really hard to support. Especially cheaper tablets send out really strange data, and it is really hard to predict what we're getting. In 3.0, we've done another rewrite... I still hope to have 3.0 pre-alpha packages out before the end of the year, ready for testing.
Created attachment 96203 [details] attachment-25076-0.html Thank you for responding. I know it's probably not a simple fix, but since my Adesso tablet works fine in the latest stable versions of Blender, Gimp, and other drawing software, I thought I should report the bug anyway. I'm no programming expert, but is there any way you can collaborate with the coders behind the abovementioned software to help with this bug? On Dec 14, 2015 1:21 AM, "Boudewijn Rempt via KDE Bugzilla" < bugzilla_noreply@kde.org> wrote: > https://bugs.kde.org/show_bug.cgi?id=352924 > > --- Comment #8 from Boudewijn Rempt <boud@valdyas.org> --- > Well, in Krita 3.0 the tablet code is rewritten once again. In 2.8 we used > Qt's > code, but that didn't support a whole bunch of tablets. In 2.9, we had our > own > code on Windows and X11, but the variety of hardware out there is really > hard > to support. Especially cheaper tablets send out really strange data, and > it is > really hard to predict what we're getting. In 3.0, we've done another > rewrite... I still hope to have 3.0 pre-alpha packages out before the end > of > the year, ready for testing. > > -- > You are receiving this mail because: > You are on the CC list for the bug. >
Just want to report that in the Krita 3.0 Alpha 1 this bug is fixed. Thank you devs for everything, finally can use Krita again :D.
Okay. Given that 2.9.x will have only one more bug fix release (on Wednesday) I guess that we can close the bug now. Thanks for checking 3.0!