GNOME Bugzilla – Bug 769112
The metadata windows takes a lot of CPU.
Last modified: 2017-07-08 12:57:28 UTC
It seems GIMP does not handle well a file which has problematic metadata. Steps: - Import the file from bug 764495, comment 6 or from bug 768950, comment 2. - Open the "Image Metadata" window. - Scroll through the tags. Result: the scrolling is extra slow, and checking a `top`, I can see a command `metadata` taking up to 100% of a CPU. Other than this, I see a bunch of tags so things work more or less, apart from the crazy CPU rampage.
Ok so I was wrong. This is probably not related to problematic metadata fields. The metadata plugin seems simply incredibly slow, taking up to 100% of a single CPU when doing stuff as basic as scrolling. This needs to be fixed.
It is fixed. In branch "gimp-attributes-wip", there is a rewritten metadata approach. I checked the images with that branch and there was no problem. (Win 10 64bit)
Created attachment 342358 [details] Glitches in the metadata GUI Hi Hartmut! So I've just tested this branch. Unfortunately the metadata process would still be very high. When I scroll on the image from bug 764495, comment 6, it could take 30, 60%, sometimes up to 99% of a CPU (Intel Core i7). The scrolling is also extra slow, and the GUI all glitchy (see the attached screenshot). :-/ The terminal would also output: > ** (metadata:1262): WARNING **: Unsupported time format > allocating: gimp-metadata-dialog Not sure if these are any useful. ------------------ Small notes: - When building the branch, I had a failure in plug-ins/common/attributes.c, line 60: _O_BINARY was not defined. Were you supposed to include <libgimpbase/gimpwin32-io.h> by any chance? - You seem to have more than just the metadata WIP on this branch, no? I could see some screenshot-related commits at least. It is better if you could have separate branches. That makes it easier to do per-topic reviews. - Finally when you are alone to work on a branch, it is advised to do a rebase rather than merging. I know this is not the usual recommendation when working with public branches, but since they are not "maintainer branches", we favour the readability of the commit history tree over keeping commit hashes. If Mitch sees that many merge commits, he'll have a heart attack! :-P
I'd like to remind that the problem is not related to a metadata bug even though I thought so at first. If I try with my own JPG photos straight from my camera, I have the same problem of slowness/CPU-eating. Adding a 2.10 milestone. It would be preferable to have a metadata plugin which does not take all the CPU before the stable release.
I cannot reproduce that problem with windows. In fact. for the ui, I used the (recommended) gtk_builder with an external .ui file. Maybe, there is a problem with that? The problem does not occur on windows. So, I assume the problem either in gexiv2.so or exiv2.so So, anyway. I cannot repair, there is a linux debug/repair required. Feel free to compile the "gimp-attributes-wip" branch. There is a rewrite in progress, but the new "attributes" plug-in will be the target of the new approach. Maybe the problem is gone with that plug-in?
> I cannot reproduce that problem with windows. Anyone else who reproduce on Linux or am I the only one experiencing not-normal processor usage for a simple dialog? > There is a rewrite in progress, but the new "attributes" plug-in will be the target of the new approach. Is this new plugin meant to replace the metadata one?
These files have some tags with very long values, which chokes GTK. Truncating long values, and hiding private tags while at it, solves this: commit f8e291bf3110098ed03e858d13b22296ec1068a4 Author: Ell <ell_se@yahoo.com> Date: Thu Dec 29 21:45:55 2016 -0500 Bug 769112 - The metadata windows takes a lot of CPU. Exif tags may have long values, which can choke GTK if we display them in their entirety. Truncate tag values (based on type, and with proper indication) to avoid that. This commit also hides private tags, and fixes some memory leaks.
So, do we consider this bug fixed by that change?
I've not tested yet the new code, but can you still see the truncated value? Like it shows with ellipsis on the main GUI, but hovering it, the tooltip text shows the full text, or something? There still need to be a way to get a value (I mean, if we have this GUI, that's to show them because we consider they are of interest to the user…).
No, we're talking here about really long values, a tooltip wouldn't do any good. It currently truncates binary values at 16 bytes (the first file has an embedded ICC profile, which is some tens of kilobytes, IIRC.) It should be enough to read version tags, or to recognize magic numbers, but if you really need all the data, GIMP is not your go-to tool. Non-binary fields are truncated at 1024 characters. The ones that get truncated in the second file are multi long tags, I think, which is practically binary data too. It should be enough to read some very long textual fields; for anything more, a treeview is not the right interface anyway. Maybe we can add a pop window with a multiline textarea, that shows the entire value when you double click it.
@Jehan: From my point of view: yes, it will replace the old one. But that's not my decision. By the way: In the new plug-in, long values are also truncated.
Tested, and that is a lot better! This small dialog does not take a crazy amount of CPU anymore, no graphics glitches, all good! > if you really need all the data, GIMP is not your go-to tool. I guess you are right! :-) > Maybe we can add a pop window with a multiline textarea, that shows the entire value when you double click it. I'm sure there would indeed be people out there who for some reason want to get the full contents of some binary contents. But then as you said above, maybe GIMP is not the right tool for the task. I'll leave you all metadata addicts to decide on this. Hartmut > ok. There are some other contributors who are patching the current metadata code (like bug 769820), so we are a little wary. We wouldn't want anyone feeling left-over with code dropped before even a release. But in the end, yes, the best code and GUI will stay. If you have a much better metadata handling plugin coming in (and we agree on the fact it's indeed better), it will be the one. ---------------- In any case, let's consider this bug fixed. New discussions on how to improve this UI or a new one can go on new bug reports.
We just got a nifty new metadata plugin (bug 769820), but its viewer part is based on a version of the old plugin that still contained this bug. So, refixing the bug in the new plugin, in master: commit 8c2ca36ac76fc5fc9aa7aa9055d2c6e4772f93b7 Author: Ell <ell_se@yahoo.com> Date: Sat Jul 8 08:48:47 2017 -0400 Bug 769112 - The metadata windows takes a lot of CPU. The new metadata viewer is based on a version of the old metadata plugin that still contained this bug, and a few other bugs that've been fixed since then. Reapply those fixes to the new plugin. This is essentially an adaptation of commits f8e291bf3110098ed03e858d13b22296ec1068a4, ce9e7feabde9b31d5847f6e533feeb0cac23f325, 38c79600f15402fd126aa572eafd444b775f56c1, and 801bd8fb3f4ac3494b571df6a260fe0f31df38f2. plug-ins/metadata/metadata-viewer.c | 234 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++----------------------------------- 1 file changed, 169 insertions(+), 65 deletions(-)