[krita] [Bug 447046] Delay when selecting a brush preset and actually having it active
https://bugs.kde.org/show_bug.cgi?id=447046 --- Comment #23 from Larissa --- (In reply to tomtomtomreportingin from comment #22) > Is this still an issue now that https://bugs.kde.org/show_bug.cgi?id=446146 > is fixed? hello, after using the recent nightly builds i can confirm this issue is completely resolved, both reloading presets and changing presets without the save temporary tweeks on have no delay whatsoever. Now, apologies but i dont know if its me that should change the status to resolved or if it should be one of the devs. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 447046] Delay when selecting a brush preset and actually having it active
https://bugs.kde.org/show_bug.cgi?id=447046 --- Comment #16 from Larissa --- Tested both builds. the problem still persists. The performance improvements do not seem to make any difference in this issue, at least for me. Unlike thetwo report, all brushes cause the delay on selection and there seems to have no relation to brush textures as even selecting basic-1 causes delay. in some cases the delay seems even worse than before, sometimes taking up to 8 seconds and freezing krita. There were also no relevant logs in the log file. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 447046] New: Delay when selecting a brush preset and actually having it active
https://bugs.kde.org/show_bug.cgi?id=447046 Bug ID: 447046 Summary: Delay when selecting a brush preset and actually having it active Product: krita Version: 5.0.0-beta5 Platform: Microsoft Windows OS: Microsoft Windows Status: REPORTED Severity: normal Priority: NOR Component: Resource Management Assignee: krita-bugs-n...@kde.org Reporter: lalak...@gmail.com Target Milestone: --- SUMMARY After testing beta5 i noticed a considerable delay when selecting brush presets in the docker. Once I click on a preset it takes 3 seconds for the new brush to be actually selected and being able to be usable. If i try to use the brush without waiting for the brush to be actually selected nothing is shown on the canvas until the brush is selected, once it appears as selected in the brush preset docker, the canvas is updated with a stroke of the brush I tried to use, but this path is not the same one I did but the shortest one between where I first clicked and where my mouse was the moment the brush appears as selected in the docker. Its good to note that this only happens when selecting the brush in the brush preset docker, when using the / shortcut to go to a previous brush the change is instantly. It might also be relevant that i have many brushes and bundles active in krita right now, around 25 active bundles. Though in beta 2 everything works fine. I tested with several versions, beta 2 everything works fine, no delays at all. the problem seems to first appear in beta 3 and persists on the beta 5 versions even for the the most recent nightly builds (all versions tested down below). I also deleted the sqlite db and opened krita again, 3 times with different builds all with the same result. STEPS TO REPRODUCE 1. Select a brush in the brush preset docker OBSERVED RESULT the brush takes 3 seconds to appear selected in the brush preset and for it to actually be usable to paint EXPECTED RESULT change betwen brushes when selected in the brush preset docker should be instantly. SOFTWARE/OS VERSIONS Windows: Windows 10 TESTED WITH VERSIONS krita-nightly-x64-5.0.0-beta5-0e4b8448bf krita-x64-5.0.0-beta5 krita-nightly-x64-5.0.0-beta5-0e4b8448bf krita-x64-5.0.0-beta3 -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 447048] New: Opening files and creating new document takes too long to load the canvas
rita\libs\resources\KisStoragePlugin.cpp, line 92 15 Dec 2021 20:20:06 -0300: Non-store package - creating updater 15 Dec 2021 20:20:35 -0300: Created image "Unnamed", 3000 * 3000 pixels, 300 dpi. Color model: 8-bit integer/channel RGB/Alpha (sRGB IEC61966-2.1). Layers: 2 15 Dec 2021 20:21:52 -0300: Importing image/png to application/x-krita. Location: F:/Larissa/Pictures/Desenhos-2019.04/Monstros/cave gremelin.png. Real location: F:/Larissa/Pictures/Desenhos-2019.04/Monstros/cave gremelin.png. Batchmode: 0 15 Dec 2021 20:21:52 -0300: Loaded image from image/png. Size: 2180 * 2216 pixels, 4.16665 dpi. Color model: 8-bit integer/channel RGB/Alpha (sRGB built-in). Layers: 2 15 Dec 2021 20:22:20 -0300: Importing application/x-krita to application/x-krita. Location: F:/Larissa/Pictures/Desenhos-2019.04/Monstros/cave gremelin.kra. Real location: F:/Larissa/Pictures/Desenhos-2019.04/Monstros/cave gremelin.kra. Batchmode: 0 15 Dec 2021 20:22:20 -0300: Loaded image from application/x-krita. Size: 2180 * 2216 pixels, 4.16667 dpi. Color model: 8-bit integer/channel RGB/Alpha (sRGB IEC61966-2.1). Layers: 5 -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 447046] Delay when selecting a brush preset and actually having it active
https://bugs.kde.org/show_bug.cgi?id=447046 --- Comment #3 from Larissa --- (In reply to Ahab Greybeard from comment #1) > I don't see this happening with the 5.0.0-beta5 or the Dec 20 5.1.0-prealpha > appimages. > I don't have many resources added. > > Can you rename your resources folder to 'krita-many-resources' (or whatever) > then start krita to get a default 'mimimal' set of resources, in a freshly > created 'krita' folder, then try this again to see if it is because of your > large number of resources? Testing with 5.0.0-beta5-f74b584402 there is indeed no lag when using a a fresh resource folder. However its good to note that the same amount of resources cause no lag at all with 5.0-beta 2, so i still consider it a huge problem. The lag is already noticeable when adding big bundles like Concept & Illustration 1.2 or FizzyFlower Essentials, even if I only have krita 4 bundle and one of these big bundles active the lag happens (not as much as with all my resources). When having only one big bundle deactivating it makes the lag disappear but if you have both bundles active as an example, deactivating both reduces the lag but doesn't stop it. As a test i added both bundles by importing the brushes and presets separately and the result is interesting as i get reduced but inconsistent lag, meaning there is a tiny bit of lag, but only sometimes, other times the change is instant. but still a shorter lag than i get by importing them as bundles. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 447046] Delay when selecting a brush preset and actually having it active
https://bugs.kde.org/show_bug.cgi?id=447046 --- Comment #8 from Larissa --- (In reply to Dmitry Kazakov from comment #6) > Hi, Larissa! > > Can you clarify a bit, does the delay happen only when you select a brush > for the first time in Krita session or every time when you select it? From > your note about '/' shortcut, I have a feeling like it should happen only > for the first click on the brush Hello, Dmitry! I decided to make some more tests with 5.0 release. Using the same resource folder I used for the previous betas I get constant delay no matter how many times I select the brush. I also have experience the delay in loading the canvas and krita stopped responding for some seconds as I reported in bug 447048. Even with a fresh resource folder, importing bundles have the exact same behavior of constant lag, no matter how many times i select the brush. Testing with a fresh resource folder: - Without any additional bundles -> change between presets is instant, canvas loading is also instant. (using 3000x3000 300ppi canvas for all these tests) - Adding FizzyFlower Essentials and Concept & Illustration 1.2 bundles, without restarting krita -> Things get a bit weird, at first seems like there is no lag when i try to change brushes, however if i keep changing seems like the lag starts appearing, after around 5 switches in sequence the lag becomes very noticiable. - Adding FizzyFlower Essentials and Concept & Illustration 1.2 bundles, after restarting krita -> Same behavior as before but once it starts lagging the lag is not as much - Adding the files(brush and presets) for both bundles, instead of importing the bundle -> there is a bit of lag sometimes but is greatly reduced. When adding more bundles even the krita 4 bundle starts lagging. Honestly the more I test the more confused I get cause the behavior is inconsistent, sometimes all brush changes lag other times just changing to brushes in the bundles lag. Seems like the bundle files create a bit more lag than having the separate files in the folders. The only thing i could conclude so far is that importing all bundles as preset and brush files seem to work as a workaround up to a certain point, as too many will get to the same slowdown. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 447046] Delay when selecting a brush preset and actually having it active
https://bugs.kde.org/show_bug.cgi?id=447046 --- Comment #12 from Larissa --- I thought it would be relevant to post this information here. Seems like checking "Temporarily save tweeks to presets" in the brush editor fixes the problem in 5.0.2. I still hope this can be fixed without needing to have this activated and hopefully this information helps into finding the problem. But seems like a workaround for now. This workaround was discovered in this thread https://krita-artists.org/t/slight-pause-when-switching-brushes/36079 -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 412102] Open recent documents doesn't load on windows
https://bugs.kde.org/show_bug.cgi?id=412102 --- Comment #6 from Larissa --- (In reply to Boudewijn Rempt from comment #5) > Hm, weird... The extra info should help, but I still haven't found a way to > reproduce. The way I think you can reproduce this bug is: 1) Change the location that one of the windows default folders (images,videos,documents, and so on...) points to. That can be done by right click and in the local tab you change the local to another drive. 2) Save the file inside the folder you changed the location it points to. 3) Try to open the file through the recent documents. What I also noticed is that the open recent in the file menu gets disabled, like there were no recent opened files at all. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 412102] New: Open recent documents doesn't load on windows
https://bugs.kde.org/show_bug.cgi?id=412102 Bug ID: 412102 Summary: Open recent documents doesn't load on windows Product: krita Version: 4.2.6 Platform: MS Windows OS: MS Windows Status: REPORTED Severity: minor Priority: NOR Component: File formats Assignee: krita-bugs-n...@kde.org Reporter: lalak...@gmail.com Target Milestone: --- SUMMARY When trying to open a document through the recent documents on the start page, on windows it will say the file doesn't exist and it puts file:/// before the path on windows. Also observed the path points to the wrong drive, it points to C drive but in my case the file is in the F drive. STEPS TO REPRODUCE 1. Open krita on windows 2. Try to open any file through the recent documents on the start page OBSERVED RESULT A warning popup saying the file doesn't exist showing the path "file:///C:/..." the drive letter was also wrong EXPECTED RESULT opening the file SOFTWARE/OS VERSIONS Windows: 10 macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 412102] Open recent documents doesn't load on windows
https://bugs.kde.org/show_bug.cgi?id=412102 --- Comment #2 from Larissa --- (In reply to Tymond from comment #1) > Did you move the file to another drive after saving? no, it was always in the same drive since the file creation. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 412102] Open recent documents doesn't load on windows
https://bugs.kde.org/show_bug.cgi?id=412102 --- Comment #4 from Larissa --- I want to add some info that might be relevant and some tests I just did. Even before installing krita at all I changed the location of windows default image folder from the drive C to F and I store all my kra files in a folder inside that one. I did 2 tests right now: 1)I saved a file inside my user folder in the F drive, created when I changed the path of the default image folder. Same result, it tries to find the file as it was in the drive C. 2)I saved a file in the drive F in a folder outside the ones created by windows, this time it worked fine, the image loaded without a problem. I hope this info helps -- You are receiving this mail because: You are watching all bug changes.
[kde] [Bug 383385] New: Bug report when open image files in midnight commander
https://bugs.kde.org/show_bug.cgi?id=383385 Bug ID: 383385 Summary: Bug report when open image files in midnight commander Product: kde Version: unspecified Platform: unspecified OS: Linux Status: UNCONFIRMED Keywords: drkonqi Severity: crash Priority: NOR Component: general Assignee: unassigned-b...@kde.org Reporter: larissa.patriciovale...@my.jcu.edu.au Target Milestone: --- Application: baloo_file (5.21.0) Qt Version: 5.5.1 Operating System: Linux 4.1.39-56-default x86_64 Distribution: "openSUSE Leap 42.1 (x86_64)" -- Information about the crash: - What I was doing when the application crashed: When I open a picture file with midnight commander, the picture file opens ok. But somehow there is a report of a crash. Nothing happens, the picture file is still there and working. The crash can be reproduced sometimes. -- Backtrace: Application: Baloo File Indexing Daemon (baloo_file), signal: Segmentation fault Using host libthread_db library "/lib64/libthread_db.so.1". [Current thread is 1 (Thread 0x7fbf491b9780 (LWP 1684))] Thread 2 (Thread 0x7fbdfe19c700 (LWP 1953)): #0 0x7fbf46ccfbfd in poll () at /lib64/libc.so.6 #1 0x7fbf43707e64 in () at /usr/lib64/libglib-2.0.so.0 #2 0x7fbf43707f7c in g_main_context_iteration () at /usr/lib64/libglib-2.0.so.0 #3 0x7fbf478fdd8b in QEventDispatcherGlib::processEvents(QFlags) () at /usr/lib64/libQt5Core.so.5 #4 0x7fbf478a4d53 in QEventLoop::exec(QFlags) () at /usr/lib64/libQt5Core.so.5 #5 0x0041531b in () #6 0x7fbf476c8382 in () at /usr/lib64/libQt5Core.so.5 #7 0x7fbf476cb32f in () at /usr/lib64/libQt5Core.so.5 #8 0x7fbf45d0c0a4 in start_thread () at /lib64/libpthread.so.0 #9 0x7fbf46cd802d in clone () at /lib64/libc.so.6 Thread 1 (Thread 0x7fbf491b9780 (LWP 1684)): [KCrash Handler] #6 0x7fbf449fc25c in mdb_get () at /usr/lib64/liblmdb-0.9.14.so #7 0x7fbf47f994cd in Baloo::IdTreeDB::get(unsigned long long) () at /usr/lib64/libKF5BalooEngine.so.5 #8 0x7fbf47f96dc0 in Baloo::DocumentUrlDB::getId(unsigned long long, QByteArray const&) const () at /usr/lib64/libKF5BalooEngine.so.5 #9 0x7fbf47fa8949 in Baloo::Transaction::documentId(QByteArray const&) const () at /usr/lib64/libKF5BalooEngine.so.5 #10 0x0041d453 in () #11 0x0041d50d in () #12 0x7fbf478d673f in QMetaObject::activate(QObject*, int, int, void**) () at /usr/lib64/libQt5Core.so.5 #13 0x00427145 in () #14 0x0041b6f6 in () #15 0x7fbf478d673f in QMetaObject::activate(QObject*, int, int, void**) () at /usr/lib64/libQt5Core.so.5 #16 0x7fbf478e3f22 in QTimer::timerEvent(QTimerEvent*) () at /usr/lib64/libQt5Core.so.5 #17 0x7fbf478d78bc in QObject::event(QEvent*) () at /usr/lib64/libQt5Core.so.5 #18 0x7fbf478a718d in QCoreApplication::notify(QObject*, QEvent*) () at /usr/lib64/libQt5Core.so.5 #19 0x7fbf478a6e95 in QCoreApplication::notifyInternal(QObject*, QEvent*) () at /usr/lib64/libQt5Core.so.5 #20 0x7fbf478fd77d in QTimerInfoList::activateTimers() () at /usr/lib64/libQt5Core.so.5 #21 0x7fbf478fdad9 in () at /usr/lib64/libQt5Core.so.5 #22 0x7fbf43707c84 in g_main_context_dispatch () at /usr/lib64/libglib-2.0.so.0 #23 0x7fbf43707ed8 in () at /usr/lib64/libglib-2.0.so.0 #24 0x7fbf43707f7c in g_main_context_iteration () at /usr/lib64/libglib-2.0.so.0 #25 0x7fbf478fdd6c in QEventDispatcherGlib::processEvents(QFlags) () at /usr/lib64/libQt5Core.so.5 #26 0x7fbf478a4d53 in QEventLoop::exec(QFlags) () at /usr/lib64/libQt5Core.so.5 #27 0x7fbf478ac8f6 in QCoreApplication::exec() () at /usr/lib64/libQt5Core.so.5 #28 0x0040a832 in () #29 0x7fbf46c14b25 in __libc_start_main () at /lib64/libc.so.6 #30 0x0040a9a8 in _start () Possible duplicates by query: bug 359672, bug 355210, bug 353223. Reported using DrKonqi -- You are receiving this mail because: You are watching all bug changes.
