359147 - big images don't redraw

Status: RESOLVED FIXED

(Core :: Graphics, defect)

Description

[Radek 'sysKin' Czyz]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20061101 Firefox/2.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20061101 Firefox/2.0

When I'm trying to open a big image, it initially downloads and displays fine. However as soon as it finished downloading, it no longer redraws - if I take another window and move in front of firefox, the image disappears.

Reproducible: Always

Steps to Reproduce:
1. Open big image (see URL)
2. Wait until it finishes loading
3. Resize firefox window, switch tabs, bring another window to front or otherwise do stuff to redraw the image again

Actual Results:  
There's whiteness instead of image. See attachment.


Using 6600GT and version 91.47 official drivers. 2048x2048 images seem fine, I don't know what the exact threshold is.

Comment 1

[Radek 'sysKin' Czyz]

Attachment: what happens if another window was moved in front of firefox

...just in case it wasn't obvious what I meant ;)

Comment 2

[Jeremy Baron]

I can't reproduce this on Linux.

Comment 3

[Justin Kerk]

Confirmed, I actually just noticed this with a different image: http://www.zaon.com/rpg/downloads/ZAON_GalaxyPosterMap.jpg

Note that you have to wait for the image to completely load before it stops redrawing.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20061101 Minefield/3.0a1 ID:2006110104 [cairo]

Comment 4

[Ria Klaassen (not reading all bugmail)]

WFM with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20061101 Minefield/3.0a1
I couldn't identify your user agent so I tried also branch but both show no problems. I resized, wiped with the options window over it, switched tabs, no problem here.

Comment 5

[Radek 'sysKin' Czyz]

(In reply to comment #4)
> I couldn't identify your user agent so I tried also branch but both show no
> problems. I resized, wiped with the options window over it, switched tabs, no
> problem here.
 
Ah sorry, I overwrote my UA (the last part) for one evil sniffing website which otherwise won't let me in. But what I use is current 3.0a1 nightly.

I switched to Minefields a couple of days ago and they all had it so far.

Comment 6

[Brian Polidoro]

2006080907 ok
2006080914 broke
which points to Bug 342366 
There's also Bug 343655 on that day but from what I recall that landed after the 2006080914 build.

Comment 7

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

(In reply to comment #6)
> 2006080907 ok
> 2006080914 broke
> which points to Bug 342366 
> There's also Bug 343655 on that day but from what I recall that landed after
> the 2006080914 build.

Are you sure that 343655 isn't in?  That would be the logical culprit, much more likely than 342366.

Comment 8

[Brian Polidoro]

(In reply to comment #7)
> 
> Are you sure that 343655 isn't in?  That would be the logical culprit, much
> more likely than 342366.
> 
I thought it wasn't.  But I also thought bug 343655 made more sense.  That's why I mentioned it.  

Tinderbox doesn't show the checkins anymore:
http://tinderbox.mozilla.org/showbuilds.cgi?tree=Firefox&maxdate=1155160484&legend=0
Maybe because the tinderboxes have changed.  

Comment 9

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

I can't actually reproduce this any more -- some of the correctness fixes I checked in yesterday may have fixed it.  Could you retest with the latest nightly?

Comment 10

[Brian Polidoro]

It does seem different.  But now it's all or nothing.  Now the whole image will disappear. And it disappears easily. Most anything will make it disappear.   Even doing nothing it will usually disappear after loading.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20061108 Minefield/3.0a1 ID:2006110811 [cairo]

Comment 11

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Hmm.  Ok, I'll do some more testing; out of curiosity, what video card/driver are you using?

Comment 12

[Brian Polidoro]

I've got a Nvidia GeForce4 MX 420.  I had drivers that were 11 months old.  Now I updated to the most recent drivers with no difference.

Comment 13

[Brian Polidoro]

It does seem system specific as my system at home does not have this problem.

Comment 14

[Radek 'sysKin' Czyz]

(In reply to comment #9)
> I can't actually reproduce this any more -- some of the correctness fixes I
> checked in yesterday may have fixed it.  Could you retest with the latest
> nightly?
 
There's no change for me :(
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20061108 Minefield/3.0a1

Comment 15

[Ria Klaassen (not reading all bugmail)]

And with my ATI Radeon IGP-320 (U1) I have never seen this specific problem at all :).

Comment 16

[Justin Kerk]

I can't reproduce this anymore - Mobile Intel 915/910 graphics

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20061109 Minefield/3.0a1 ID:2006110904 [cairo]

Comment 17

[Justin Kerk]

Actually, the ZAON image works now (and didn't before) but the NASA one still disappears.

Comment 18

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

A simple fix here would just be to not optimize images that are beyond a certain size, probably anything that's bigger than 2K in either direction.

Comment 19

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Attachment: don't put big images in DDBs

Don't optimize big images into DDBs; I consider this a bandaid though, we should figure out how to detect whether something failed or not when creating the DDB.  I couldn't find any way to query the system for the max size of a DDB, however, after reading a bunch of info on http://www.efg2.com/Lab/Graphics/VeryLargeBitmap.htm , the solution seems to be:

# Don't create DDB's that are larger than the screen.
# Don't create/blt DDB's from a DIB, were the memory consumption of the source rectangle exceeds the memory consumption of the screen.

1kx1k still might cause problems on some systems, so we should actually do the screen size query; but getting that info to here is a bit harder, and this should do for the alpha.

Comment 20

[Stuart Parmenter]

Comment on attachment 245255 [details] [diff] [review]
don't put big images in DDBs

can you make those a define or const somewhere?

Comment 21

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Patch checked in; clearing blocking1.9a1+, we should revisit this for the release to make it more robust.

Please let me know if this still appears in tomorrow's nightly (or later).