RSS/Atom feed Twitter
Site is read-only, email is disabled

Inconsistent Behaviour of New View Windows

This discussion is connected to the gimp-user-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.

This is a read-only list on gimpusers.com so this discussion thread is read-only, too.

5 of 5 messages available
Toggle history

Please log in to manage your subscriptions.

Inconsistent Behaviour of New View Windows programmer_ceds 15 May 22:33
  Inconsistent Behaviour of New View Windows Michael Schumacher 15 May 22:44
  Inconsistent Behaviour of New View Windows Michael Schumacher 15 May 22:45
   Inconsistent Behaviour of New View Windows programmer_ceds 16 May 08:41
    Inconsistent Behaviour of New View Windows Michael Schumacher 16 May 21:09
2017-05-15 22:33:29 UTC (over 7 years ago)
postings
121

Inconsistent Behaviour of New View Windows

To quote from the V2.8 on-line documentation for the New View menu command:

"Any change, other than viewing changes, which you make in one window also appear in the other displays which show the same image. The new views are not separate image files; they are simply different aspects of the same image. You might use multiple views, for example, if you were working on individual pixels at a high zoom factor. You could then see the effects your changes would have on the image at a normal size."

At the moment I think that this really only applies to the airbrush and the colour tools (Levels, Curves, Brightness etc).

The paintbrush type tools (pencil, eraser etc) do reflect the changes but only when the mouse button is released (whereas the airbrush shows the line in all of the views as it is being drawn).

More importantly the additional views are not updated during transform operations. In fact with the later versions of 2.9.5, in which the active layer is made transparent when the transform tool is activated, the additional views of an image with only one layer all change to the chequerboard pattern - which looks a bit odd and may be the cause of a number of questions/bug reports.

Displaying the transform preview in the additional views would conform to the aim stated in the documentation of allowing views of the changes at different magnifications to that used for the active view. In particular it would allow a higher magnification to be used for an additional view to see the effects of the Unified Transform tool - where you can't zoom the active view otherwise the control handles are not visible and all you can do is rotate or move the image. Obviously this isn't a problem for the perspective, shear etc tools as the actions still accessible when zoomed in.

Changing the paint tools so that they reflect the changes 'in real time' is trivial - in functions gimp_paint_tool_button_press() and gimp_paint_tool_motion() use the existing gimp_display_flush_now (display) call when the image has only one display (this makes the program more responsive), otherwise use gimp_image_flush(image).

Unfortunately, however, I don't have the experience to suggest changes to make the transform preview appear in the additional views - this being by far the more useful change.

Michael Schumacher
2017-05-15 22:44:25 UTC (over 7 years ago)

Inconsistent Behaviour of New View Windows

On 05/16/2017 12:33 AM, programmer_ceds wrote:

Changing the paint tools so that they reflect the changes 'in real time' is trivial - in functions gimp_paint_tool_button_press() and gimp_paint_tool_motion() use the existing gimp_display_flush_now (display) call when the image has only one display (this makes the program more responsive), otherwise use gimp_image_flush(image).

And this doesn't have a performance impact with large images and brushes?

As you figured out what to change, would you like to create a patch against git master and file an enhancement request for this?

Regards,
Michael
GPG: 96A8 B38A 728A 577D 724D 60E5 F855 53EC B36D 4CDD
Michael Schumacher
2017-05-15 22:45:21 UTC (over 7 years ago)

Inconsistent Behaviour of New View Windows

On 05/16/2017 12:33 AM, programmer_ceds wrote:

To quote from the V2.8 on-line documentation for the New View menu command:

BTW, this would have been more suitable for the gimp-developer mailing list.

Regards,
Michael
GPG: 96A8 B38A 728A 577D 724D 60E5 F855 53EC B36D 4CDD
2017-05-16 08:41:35 UTC (over 7 years ago)
postings
121

Inconsistent Behaviour of New View Windows

BTW, this would have been more suitable for the gimp-developer mailing list.

I'm not a member of the gimp-developer mailing list - perhaps I should join - can I join?

There is a speed penalty so it might be as well to add an option to Preferences to allow the user to turn this feature off. But even then the behaviour of the views would not be consistent as the airbrush would (unless modified from its current behaviour) still update the additional views as it is used.

Whilst it may be helpful to modify the paint tools in this way my aim was to modify the transform tools so that the preview appears in all views - thereby adding to the usability of the Unified Transform tool.

If someone could give me any pointers on how this might be achieved I would be pleased to look further at it.

I have only just started looking at the gimp sources and trying to build it on Windows (with some success but I still have a few things to sort out) so I'm not familiar with the inner workings of the program. I had assumed that there would be a single canvas for each image and that all of the views for the image were simply apertures on to this single canvas. So when the canvas had been altered it was simply a case of redisplaying the appropriate portions in the one or more views. Given the speed at which the image viewer I use can switch between two full screen images I was expecting that the generally smaller additional views would not take long to refresh.

On a separate matter - when compiling/building gegl and gimp there are numerous warnings displayed (some of these are, I think, only output when building on/for Windows). I could work at eliminating these warnings to allow a clean build if such changes would be welcome. Any warnings that then appear as the result of future changes will then stand out and can be addressed or suppressed as appropriate.

Michael Schumacher
2017-05-16 21:09:27 UTC (over 7 years ago)

Inconsistent Behaviour of New View Windows

On 05/16/2017 10:41 AM, programmer_ceds wrote:

BTW, this would have been more suitable for the gimp-developer mailing list.

I'm not a member of the gimp-developer mailing list - perhaps I should join - can I join?

Yes, you should, and yes, you can - it is a mailing list, so all you need is an email address and a web browser to go to:

https://mail.gnome.org/mailman/listinfo/gimp-developer-list

There is an alternative:

Being on IRC can be even more helpful, especially if you need advice in real-time if you are trying to figure out how some code works *right now*.

Most of the discussions alongside GIMP development actually happen on IRC, the server is irc.gimp.org and the channel is #gimp. Make sure you can join during European evenings and be prepared to stay for hours at a time.

There is a speed penalty so it might be as well to add an option to Preferences to allow the user to turn this feature off. But even then the behavior of the views would not be consistent as the airbrush would (unless modified from its current behaviour) still update the additional views as it is used.

Well, this would be a whole new paradigm of behavior being introduced, so how something behaves right now is of lesser importance.

Whilst it may be helpful to modify the paint tools in this way my aim was to modify the transform tools so that the preview appears in all views - thereby adding to the usability of the Unified Transform tool.

If someone could give me any pointers on how this might be achieved I would be pleased to look further at it.

Again, IRC - direct, real-time interaction with the developers.

I have only just started looking at the gimp sources and trying to build it on Windows (with some success but I still have a few things to sort out) so I'm not familiar with the inner workings of the program.

The changes you have done to make painting work across all views would be interesting to see. This is where attaching a patch to an enhancement request in Bugzilla is a good approach.

Regards,
Michael
GPG: 96A8 B38A 728A 577D 724D 60E5 F855 53EC B36D 4CDD