New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
filmulator churning away on CPU even when idle #114
Comments
Honestly this is a bit out of my hands. I think it's something to do with the way the QML rendering engine works on MacOS, but I'm not sure. On Linux I never have this issue, ever, and in my testing on Windows I think the CPU spikes mainly when there's visible animation (such as in the import tab when the source directory box is pulsing). You may want to try a different version of Qt; Filmulator should work with anything as far back as 5.12. |
Ok, I'll see if I can download a few versions of Qt and see if any behave differently then. |
Again, in my experience, on Windows it only happens when animation is occurring, which is almost entirely on the Import tab, not all of them. I wonder Qt 6 can improve this by switching to Metal? |
Confirmed |
I wonder if it's related to the heart-beating orange bars? |
I can try replacing them with blinking… but I really liked the heartbeat effect, being very visible but not alarming. |
I replaced the heartbeat effect with an error icon, now that I've figured out how to do icons. Now there's no idle CPU usage in Windows at all; if there is any in MacOS then I'm not sure what more I can do. Try the current dev, though be aware that it no longer works with 5.12; I made some changes to deal with Qt 5.15's deprecation warnings for syntax that'll change in Qt 6. It works with 5.14 and 5.15 for sure. |
I updated Qt and got the latest dev version, but I'm having trouble getting it to build now. I think I have all right versions of the dependencies. Here's my error messages:
Any idea what might be going wrong? |
I made changes and you now need Lensfun 3.95 exactly, not git master. |
I thought I did have 0.3.95, at least that's what it says it is. Maybe 0.3.95 != 0.3.95... I'll try downloading and compiling the release since it doesn't seem to want to find the homebrew installed version either. |
You're right, that's what it was. Well, the CPU usage is greatly improved! However, I'm getting a crash when I try to load an image. First, here's the numbers with it just idling in the background: Import tab: filmulator 0%, WindowServer ~1.5% The CPU % numbers go up a little when I interact with filmulator like you would expect, and then go back down to 0%. Much, much improved, and acting how you would expect it to! However, that crash... It just crashes instantly when I try to open an image. Here's the output when I run it from a terminal:
|
Can you upload the offending raw file? |
Sure. It doesn't seem to matter what image it is, maybe it's the camera I've taken it with. Here's a zip file with the image - It's one I had imported with the older build and I successfully exported it then. |
Okay, so there's no crash on my end with the file. Can you try running the testbuild branch? I put some output around where I think the crash may be occurring... |
It did give a different error message:
Probably useful to note this was taken with an adapted lens, so even the camera has no idea what lens it is, apart from the user-defined focal length. And even that's a crapshoot depending on whether I bother to change it at the time. |
On a hunch I deleted the folder "version_2" from lensfun referenced in the above crash and filmulator seems to have re-grabbed the now correct lensfun data - I no longer get a crash when trying to load an image. CPU usage is the same as with no image loaded - it goes up to 100% cpu while processing the image, and then drops down to 0% once the image has been processed. Edit: Interesting behavior. the version_2 directory was not regenerated at startup like I thought. I hit the Update Lens Correction Database button and got Update Successful, then tried to load a new image and got the same crash. |
I pushed a change to testbuild that should fix the problem, based on other lensfun example code. |
I'll give it a shot. Stay tuned. |
Looks like that wasn't it - In this output I loaded a file, hit the "Update Lens Correction" to regenerate that directory, and then tried to load a different file and it crashed. Here's the output:
EDIT: Should probably write down what commit this was at - e981dee on testbuild |
If I'm reading the debug output correctly, you interrupted the first image loading with a different image, and then it crashed? Does it finish loading the first image at full resolution? I've made another push that should give me some more insight into where it's crashing. |
I believe it had fully loaded the first image, but I can try again to check. It does successfully load an image - and I can export jpgs and tiffs - as long as that version_2 directory does not exist. I'll try the new changes. |
Ok, here's commit dd8460c - without version_2 directory:
After clicking Update lens correction database (version_2 directory exists now):
Actually, I wonder if the lensfun data it's grabbing is bad somehow... Let me peek at that xml file it's referencing. Maybe it's trying to grab the previous install's data rather than 0.3.95. Edit: I'll attach a zip file with the file in question, but there doesn't seem to be anything obviously wrong with it. |
Your XML file is the same as mine. I don't get why the problem is occurring... But I just made another commit to testbuild, commit dd8460c. Turns out that where the lensfun library is crashing, I didn't need to use it at all. Maybe this will help, maybe it won't. |
Did you mean commit 7875c67? Not out of the woods yet it seems. Here's the output:
|
I wonder if MacOS is being stricter about things than Linux. I'll try valgrind tonight. |
What compiler are you using? Could you try to capture a stack trace? |
I believe it's clang++. |
Can you try to capture a stack trace? It might be an upstream problem in lensfun. Tonight I'll see if I can allocate lensfun on the stack to prevent these problems. |
I'm not actually familiar with what a stack trace looks like, but I think it's contained in the crash debug output here: |
I may have to make some sort of flag that lets you use the git master Lensfun for Mac and 0.3.95 for Windows and Linux; the git version worked for you, right? |
Yeah, the git master version of lensfun worked on the previous build before you required the 0.3.95 release. That version reported itself as 0.3.95 but apparently had some fundamental difference that made it incompatible. |
Yeah, the function signatures changed. |
I just went and looked at the lensfun commit history, that is a lot of changes since the last release. Almost 2 years! And what must be hundreds of commits. Edit: 14 pages! |
I'll test it tonight after work to see exactly what the behavior is, but one interesting thing is that if I do not do the "Update lens correction database" and make sure the version_2 directory doesn't exist, the lens correction list is actually still populated. Not sure if that is a clue for you or not. Edit: it appears I was wrong about this, please disregard |
I just pushed a change that should make it use the latest git version's API for MacOS only. If it fails to compile with 0.3.95, then what I did worked, and you should try building Lensfun from git again. |
Commit 3d81eb8 - Success! I can successfully import an image, add it to the queue, open it, and save a jpeg and tiff now. And it is indeed using the master branch of lensfun - I made sure the build failed with 0.3.95 installed. |
And back to the issue at hand, how is the idle CPU usage? Can we close the issue? |
Right. Here's the numbers with the latest and greatest working build - all just idling in the background: Import tab: filmulator 0%, WindowServer ~1.5% I think I would call that problem solved. Edit: laptop runs nice and cool now, too 👍 |
On MacOS, latest dev branch: Something in filmulator seems to be not terribly efficient - here are the CPU % numbers just when sitting there:
Import tab: filmulator ~13%, WindowServer ~15%
Organize tab: filmulator ~25%, WindowServer ~10%
Filmulate tab (with image open, after letting it fully process current settings): filmulator ~13%, windowserver ~20%
Settings tab: filmulator ~13%, windowserver ~15%
My laptop is noticeably hot when filmulator is just sitting there idling in the background, and it absolutely chews through battery. I mention the WindowServer process because that seems to be tracking pretty clearly with filmulator - when I close it, it goes down to ~0.5-1%.
What is filmulator doing when it's just sitting there? It must be churning away on something, or forcing window redraws constantly?
I'm not sure what else I can do to get more info on what it's doing.
The text was updated successfully, but these errors were encountered: