Closed Bug 641599 Opened 9 years ago Closed 9 years ago

Layer is not cleaned after image zooming with Ctrl+

Categories

(Core :: Graphics, defect)

x86
All
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla5
Tracking Status
blocking2.0 --- -

People

(Reporter: jk1700, Assigned: roc)

References

Details

(Keywords: regression, Whiteboard: [fx4-rc-ridealong])

Attachments

(2 files)

User-Agent:       Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b13pre) Gecko/20110313 Firefox/4.0b13pre
Build Identifier: 

When the image is resized with Ctrl+/Ctrl- the layer containing the previous size is not cleaned up, see the screenshot

Reproducible: Always

Steps to Reproduce:
1. Open any image in the browser, i.e. http://i.imgur.com/3HImp.png
2. Click on the image to fit it in the screen
3. Press Ctrl+ few times
Actual Results:  
Parts of the smaller size are still visible

Expected Results:  
Only actual size should be visible
Version: unspecified → Trunk
Attached image screenshot
Keywords: regression
2011-03-11 - good
2011-03-12 - bad

regression range http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=823105711a3b&tochange=d8fe8514d7e6
Regression window:
Works:
http://hg.mozilla.org/mozilla-central/rev/e00e8ee0aeb7
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b13pre) Gecko/20110310 Firefox/4.0b13pre ID:20110310221006
Fails:
http://hg.mozilla.org/mozilla-central/rev/3570861040e9
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b13pre) Gecko/20110311 Firefox/4.0b13pre ID:20110311000203
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=e00e8ee0aeb7&tochange=3570861040e9
Regressed by:
3570861040e9	Chris Jones — Bug 637Regression window:
Works:
http://hg.mozilla.org/mozilla-central/rev/e00e8ee0aeb7
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b13pre) Gecko/20110310 Firefox/4.0b13pre ID:20110310221006
Fails:
http://hg.mozilla.org/mozilla-central/rev/3570861040e9
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b13pre) Gecko/20110311 Firefox/4.0b13pre ID:20110311000203
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=e00e8ee0aeb7&tochange=3570861040e9
Regressed by:
3570861040e9	Chris Jones — Bug 637822: Translate invalidated content by the offset at which it was made valid. r=roc a=b822: Translate invalidated content by the offset at which it was made valid. r=roc a=b
Blocks: 637822
blocking2.0: --- → ?
Sorry bug spam, paste miss in comment#5,

Regression window:
Works:
http://hg.mozilla.org/mozilla-central/rev/e00e8ee0aeb7
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b13pre) Gecko/20110310
Firefox/4.0b13pre ID:20110310221006
Fails:
http://hg.mozilla.org/mozilla-central/rev/3570861040e9
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b13pre) Gecko/20110311
Firefox/4.0b13pre ID:20110311000203
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=e00e8ee0aeb7&tochange=3570861040e9
Regressed by:
3570861040e9    Chris Jones — Bug 637822: Translate invalidated content by the
offset at which it was made valid. r=roc a=b
Status: UNCONFIRMED → NEW
Ever confirmed: true
Assignee: nobody → roc
I think the problem here is that zooming changes the appunits-to-device-pixel ratio, which effectively invalidates all the cached information on layers that's expressed in appunits.
Attached patch fixSplinter Review
Writing a test for this seems rather difficult.
Attachment #519323 - Flags: review?(tnikkel)
Comment on attachment 519323 [details] [diff] [review]
fix

Is it enough to just invalid the contents all thebes layers? What about some of the properties we store?
ThebesLayerInvalidRegionProperty is removed by this call. ThebesLayerLastPaintOffsetProperty is irrelevant if there is no ThebesLayerInvalidRegionProperty. I think that's all we have in appunits.
Ok. Things that are cached in any unit could need to be recalculated though, no?
There will be a complete restyle and reflow, which should take care of most things. The issue here is that the meaning of appunits has changed. Appunits stored in the frame tree will be updated by the reflow, but these cached appunit properties will not.
I can't reproduce this on Windows 7 - is it specific to certain drivers?
We'd take this on branch, but I don't think we'd hold Firefox 4 for this as it's not 100% reproducible for everyone. (Several people tested, some saw it, most didn't)

Do we know why that is?
blocking2.0: ? → .x+
Whiteboard: [fx4-rc-ridealong]
(In reply to comment #13)
>  is it specific to certain drivers?
I do not think so. 
This happens on Windows 7,WindowsXP and Ubuntu10.04.

*Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b13pre) Gecko/20110315 Firefox/4.0b13pre ID:20110315030415
Graphics
  Adapter Description: ATI Radeon HD 4300/4500 Series
  Vendor ID: 1002
  Device ID: 954f
  Adapter RAM: 512
  Adapter Drivers: aticfx64 aticfx64 aticfx32 aticfx32 atiumd64 atidxx64
atiumdag atidxx32 atiumdva atiumd6a atitmm64
  Driver Version: 8.821.0.0
  Driver Date: 1-26-2011
  Direct2D Enabled: true
  DirectWrite Enabled: true (6.1.7601.17514, font cache n/a)
  WebGL Renderer: Google Inc. -- ANGLE -- OpenGL ES 2.0 (ANGLE 0.0.0.541)
  GPU Accelerated Windows: 1/1 Direct3D 10
 
*Mozilla/5.0 (Windows NT 5.1; rv:2.0b13pre) Gecko/20110315 Firefox/4.0b13pre ID:20110315030415
Graphics
  Adapter Description: VMware SVGA II
  Vendor ID: 15ad
  Device ID: 0405
  Adapter RAM: Unknown
  Adapter Drivers: vmx_fb
  Driver Version: 11.6.0.35
  Driver Date: 4-21-2010
  Direct2D Enabled: Blocked on your graphics card because of unresolved driver issues.
  DirectWrite Enabled: false (0.0.0.0, font cache n/a)
  WebGL Renderer: Google Inc. -- ANGLE -- OpenGL ES 2.0 (ANGLE 0.0.0.541)
  GPU Accelerated Windows: 0/1

*Mozilla/5.0 (X11; Linux i686; rv:2.0b13pre) Gecko/20110315 Firefox/4.0b13pre ID:20110315030415
Graphics
   GPU Accelerated Windows0/2
blocking2.0: .x+ → ?
OS: Windows 7 → All
blocking2.0: ? → .x+
(In reply to comment #8)
> Created attachment 519323 [details] [diff] [review]
> fix
> 
> Writing a test for this seems rather difficult.

Because it would have to combine enablePrivilege (to set nsIMarkupDocumentViewer.fullZoom) with invalidation testing like in the reftest harness?
(In reply to comment #12)
> There will be a complete restyle and reflow, which should take care of most
> things. The issue here is that the meaning of appunits has changed. Appunits
> stored in the frame tree will be updated by the reflow, but these cached
> appunit properties will not.

Yeah, I mainly meant any other properties stored by FrameLayerBuilder or in the layer tree.
The layer tree doesn't have any appunits stuff in it, by design.

FrameLayerBuilder's properties other than ThebesLayerInvalidRegionProperty and ThebesLayerLastPaintOffsetProperty don't use appunits.

So for those other properties and the layer tree, a zoom isn't any different from any other complete restyle and reflow.
Duplicate of this bug: 644223
Summary: Layer is not cleaned after image resizing with Ctrl+ → Layer is not cleaned after image zooming with Ctrl+
Whiteboard: [fx4-rc-ridealong] → [fx4-rc-ridealong][not-ready]
There doesn't seem to be enough certainty in this bug to make a 4.0.1 release. Get it into FF5 and we can then think about whether it's worth it.
blocking2.0: .x+ → -
Duplicate of this bug: 647900
Duplicate of this bug: 648234
Attachment #519323 - Flags: review?(tnikkel) → review+
Keywords: checkin-needed
Whiteboard: [fx4-rc-ridealong][not-ready] → [fx4-rc-ridealong][needs landing]
http://hg.mozilla.org/projects/cedar/rev/1a53dc7c5c20
Keywords: checkin-needed
Whiteboard: [fx4-rc-ridealong][needs landing] → [fx4-rc-ridealong][fixed-in-cedar]
http://hg.mozilla.org/mozilla-central/rev/1a53dc7c5c20
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Whiteboard: [fx4-rc-ridealong][fixed-in-cedar] → [fx4-rc-ridealong]
Target Milestone: --- → mozilla2.2
You need to log in before you can comment on or make changes to this bug.