When a tool that affects the current pixbuf is open, resizing the window will cause the pixbuf to resize inappropriately (#3887, part II)
Submitted by cli..@..ba.org
Assigned to cli..@..ba.org
Link to original bug (#718027)
Description
---- Reported by clinton@yorba.org 2011-08-24 12:53:00 -0700 ----
Original Redmine bug id: 4019
Original URL: http://redmine.yorba.org/issues/4019
Searchable id: yorba-bug-4019
Original author: Clinton Rogers
Original description:
Steps to reproduce:
View any image large enough to support editing, but smaller than the window, in a PhotoPage.
Invoke one of the tools. Notice that the image is normally-sized at this point.
Resize the window and observe the results.
Notice that the image is expanded to fit the window.
Based on discussion and experimentation from yesterday, we know that the image will get expanded to fit the window if the tool itself returns null when asked for a preview pixbuf. What may be happening is that resizing the window causes the preview pixbuf to get discarded (which is the Right Thing if the image is too large to fit the window without scaling down, but wrong if it will fit).
Related issues:
- duplicated by shotwell - 4020: Redeye: Applying the first in a sequence of redeye instan... (Duplicate)
---- Additional Comments From shotwell-maint@gnome.bugs 2013-05-01 11:38:00 -0700 ----
History
Comment 1
Updated by Clinton Rogers about 2 years ago
- Category set to 4
- Assignee set to Clinton Rogers
- Priority changed from Normal to High
- Target version set to 0.11.1
Comment 2
Updated by Clinton Rogers about 2 years ago
Experimentation and examination of the code reveals that the following sequence of events is occurring:
User clicks on button to invoke tool.
The new tool is asked for a preview pixbuf.
The new tool doesn't know about the current photo, has no way of obtaining it because it hasn't been passed a valid PhotoCanvas yet, and as such, cannot generate a preview pixbuf of it, and returns null.
The EditingHostPage sees that the preview pixbuf was null, and has to generate its own (full-window) preview pixbuf, along with an attendant Scaling.
The preview pixbuf the host page generated in step four is put into a new PhotoCanvas.
The new PhotoCanvas is passed to the newly-activated tool, along with the (now wrongly-sized) preview pixbuf and (incorrect) Scaling, which it ends up using to do its work.
Any time the preview pixbuf needs to change, either because the tool has modified the pixel data or the size of the window the preview is drawn in has been modified, the new (incorrectly sized) preview is drawn over what was there before (which we don't repaint unless we need to), causing the image to appear to suddenly 'pop' to the size of the window.
To fix it, in activate_tool, we'll create the photo canvas first and pass it to the incoming tool before asking for the preview pixbuf. This will ensure that the tool itself gets to decide what scaling should be applied, etc. In addition to fixing the sudden resize and incorrect coordinate problems, this lays the groundwork for being able to have a tool tell us what zoom level it wants, which will help #3592 when it comes time to implement it.
Comment 3
Updated by Clinton Rogers about 2 years ago
- Status changed from Open to Review
Comment 4
Updated by Jim Nelson about 2 years ago
- Status changed from Review to Open
Clinton and I discussed and determined what the core problem is. He will be providing a new patch shortly.
Comment 5
Updated by Clinton Rogers about 2 years ago
- Status changed from Open to 5
- Resolution set to fixed
Fixed in 1a5612b6.
(the commit is marked #3887 (closed), since this bug was part of that.)
Comment 6
Updated by Charles Lindsay 7 months ago
- Status changed from 5 to Fixed
--- Bug imported by chaz@yorba.org 2013-11-25 21:54 UTC ---
This bug was previously known as bug 4019 at http://redmine.yorba.org/show_bug.cgi?id=4019
Unknown Component Using default product and component set in Parameters Unknown milestone "unknown in product shotwell. Setting to default milestone for this product, "---". Setting qa contact to the default for this product. This bug either had no qa contact or an invalid one.
Version: 0.11.1
Resolution: RESOLVED FIXED