After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 769112 - The metadata windows takes a lot of CPU.
The metadata windows takes a lot of CPU.
Status: RESOLVED FIXED
Product: GIMP
Classification: Other
Component: General
git master
Other All
: Normal normal
: 2.10
Assigned To: GIMP Bugs
GIMP Bugs
Depends on:
Blocks:
 
 
Reported: 2016-07-23 15:29 UTC by Jehan
Modified: 2017-07-08 12:57 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Glitches in the metadata GUI (197.80 KB, image/png)
2016-12-22 00:22 UTC, Jehan
Details

Description Jehan 2016-07-23 15:29:01 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.
Comment 1 Jehan 2016-08-18 16:15:44 UTC
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.
Comment 2 Hartmut Kuhse 2016-08-28 05:54:37 UTC
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)
Comment 3 Jehan 2016-12-22 00:22:17 UTC
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
Comment 4 Jehan 2016-12-22 00:26:47 UTC
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.
Comment 5 Hartmut Kuhse 2016-12-29 19:07:40 UTC
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?
Comment 6 Jehan 2016-12-29 19:46:58 UTC
> 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?
Comment 7 Ell 2016-12-30 03:17:57 UTC
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.
Comment 8 Michael Schumacher 2016-12-31 00:20:15 UTC
So, do we consider this bug fixed by that change?
Comment 9 Jehan 2016-12-31 01:15:26 UTC
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…).
Comment 10 Ell 2016-12-31 01:36:24 UTC
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.
Comment 11 Hartmut Kuhse 2016-12-31 12:01:54 UTC
@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.
Comment 12 Jehan 2017-01-01 19:37:04 UTC
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.
Comment 13 Ell 2017-07-08 12:57:28 UTC
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(-)