A large image is not painted on the screen under some zoom settings

RESOLVED WORKSFORME

Status

()

RESOLVED WORKSFORME
3 years ago
3 years ago

People

(Reporter: mayankleoboy1, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: gfx-noted)

Attachments

(1 attachment)

(Reporter)

Description

3 years ago
Created attachment 8599091 [details]
memory-report.json.gz

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.0
Build ID: 20150428030209

Steps to reproduce:

1. Create a new profile
2. Disable e10s. Restart
3. Go to :  https://bugzilla.mozilla.org/showdependencygraph.cgi?id=699820
4. Zoom in-Zoom out a few times randomly.


Actual results:

1.The image may/may not  paint on the screen under some zoom values.
2. The memory usage grows quite a lot : ~1 GB for image only.  This may not be a bug, though.


Expected results:

not so.
What happens with e10s?
Whiteboard: gfx-noted
(Reporter)

Comment 2

3 years ago
happens with e10s also.

Comment 3

3 years ago
Another repro for probably the same bug:

1. Open https://ia800300.us.archive.org/25/items/Kazbeg_Panorama.jpg/Kazbeg_Panorama.jpg in Firefox 41 on Windows
2. Click to zoom in
3. Observe that image is never redrawn zoomed-in
Neither steps in comment 0 or 3 reproduce this for me. Can either of you check the latest Firefox Nightly? Thanks

https://nightly.mozilla.org/
(In reply to ivan from comment #3)
> Another repro for probably the same bug:
> 
> 1. Open
> https://ia800300.us.archive.org/25/items/Kazbeg_Panorama.jpg/Kazbeg_Panorama.
> jpg in Firefox 41 on Windows
> 2. Click to zoom in
> 3. Observe that image is never redrawn zoomed-in

I can't reproduce on Nightly on OS X, but the image requires about 650MB to decode fully. If the favicon code decides to decode a second copy of the image (which it sometimes seems to, for reasons I don't fully understand) then we'd hit the memory limit, which might cause subsequent decode attempts to fail. (If this is the cause, then bug 1119455 is related or even the same bug.)

Bug 1183852 is also related, and may have actually fixed this bug on Nightly.

Comment 6

3 years ago
(In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #4)
> Neither steps in comment 0 or 3 reproduce this for me. Can either of you
> check the latest Firefox Nightly? Thanks

Sorry, I should have been really specific.  Yes, I can reproduce my comment 3 in all of

Firefox Nightly (64-bit) 42.0a1 (2015-07-29)
Firefox Developer Edition (32-bit) 41.0a2 (2015-07-29)
Firefox Developer Edition (64-bit) 41.0a2 (2015-07-29)
Firefox Beta (32-bit) 40.0

on Windows 8.1 x64, on both my host machine and a VMWare VM.

On the host machine, the problem happens only when Firefox is started in an RDP session, or if Direct2D is otherwise disabled with gfx.direct2d.disabled -> true.
(Reporter)

Comment 7

3 years ago
cant repro anymore.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.