To reproduce: - Open 5 tabs - Open the url in the 6th tab, you should see the favicon in the tab - Minimise the browser window and restore it again After that I've lost my favicon on the tab, when I hover over the tab, it comes suddenly back again. Apparently, it only happens when the tab is at the right side of the screen, when it is the 6th tab or further. Maybe the resolution of the screen is also important. I have a 1440*900 resolution, using NVidia GeForce Go 7300, 32bit color depth. This regressed when cairo was landed on windows trunk, but it was much worse at that time, favicons didn't display at all at the tabs at that time, it seems.

I have a 1024x768 resolution using ATI RADEON IGP 340M at 32-bit color depth and am experiencing this problem as well. It must be the fourth tab from the right (5 1/2th tab from the left when I have more than 10 tabs open) to exhibit this problem. If I open the URL history bar or the Windows Start menu over the tab's favicon and then close the resulting menu, the tab is correct. I tested with two PNGs uploaded to ImageShack. The first PNG (http://img217.imageshack.us/img217/1016/5240doorxv5.jpg) exhibits the behaviour already described. However, when I made the tab with the second PNG active (http://img215.imageshack.us/img215/4205/faviconbug2lq5.png), it draws a bad favicon, even though it was correct when I hovered it. The only difference I can see is the image size (883x698 pixels on the first compared to 1024x768 pixels on the second). It draws correctly when activated if it is not one of the rightmost 4 tabs. Thank you. Andrew Browser ID: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a3) Gecko/20070322 GranParadiso/3.0a3

Testing on my Linux machine running Ubuntu Dapper Drake 6.06 shows me that this indeed happens on Linux too; however instead of a corrupted favicon, I do not get one at all after minimizing and restoring. Both PNGs exhibit the behaviour that when I make the tab active, it draws a bad favicon even though it was correct when I hovered over it. Except, on my Linux machine all deviations only happen with the rightmost tab. The graphics resolution is 800x600 on an Intel i810 so this may be why. I am using the Gran Paradiso Alpha 3 binary build. Thank you. Andrew Browser ID: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a3) Gecko/20070322 GranParadiso/3.0a3 uname -a: Linux NAMERICA1 2.6.15-23-386 #1 PREEMPT Tue May 23 13:49:40 UTC 2006 i686 GNU/Linux

After more testing on my Linux machine, it seems that the second PNG I used (http://img215.imageshack.us/img215/4205/faviconbug2lq5.png) never has a valid favicon unless I hover over it. If I scroll the tab bar, make that tab active, or make Gran Paradiso lose focus, it draws a corrupted (not blank) favicon. The only ways to restore the correct favicon is to either hover the tab or open the URL bar over it (if it reaches) And this second PNG also exhibits it when it is one of the right two 1/2 tabs, unlike the first PNG which only exhibits it if it is the right-most tab. For what I mean by "two 1/2", see http://img50.imageshack.us/img50/4582/firefoxbrokenfaviconoq0.png. Thank you. Andrew

Hrm, so I used to be able to reproduce this at will (not necessarily minimise/restore, just corrupt favicons in general), but now I can't seem to do it.

Never mind, I can reproduce again -- the key seems to be to open up a bunch of tabs, usually going into overflow, and then switching back and forth between tabs with images. I don't need to minimize/restore to reproduce.

Ok; this is a cairo bug. Basically what's happening is that due to some 16.16 fixed point math, the destination coordinate space ends up being limited to 32768 / (src_size / scale_factor); for 16x16 favicons and large images (e.g. 1024 in width), this ends up being 512 pixels. I'm working on getting this fixed.

Bug testcase. The data URLs create a 2048x32 image; the correct result should be two 16x16 squares with RGBY quadrants. Instead we get 1 correct square and either nothing or bogus rendering.

Here's a fix. If we hit a case where we'd end up with corruption, we instead downscale the image first (drawing to 0,0 in a temporary surface) and then just draw the downscaled version without scaling.

Comment on attachment 266442 [details] [diff] [review] a fix + if (aDestRect.pos.x * (1.0 / xscale) > 32768.0 || + aDestRect.pos.y * (1.0 / yscale) > 32768.0) Make these >= Do we have to worry about negative offsets?

Checked in, with >=... I don't /think/ we have to worry about negative offsets. Don't think.

The user-space-to-image-space transform in the testcase is 128 0 0 2 32768 0 So the core problem here was that the user-space-to-image-space transform was not representable in a pixman_fixed_16_16_t.

Er, I think that's -32768 in the last line there. That matrix is fine for the first image, but for the second image the translation is -32896 which is out of range so everything falls apart.

vlad: is AutoCairoPixmanBugWorkaround still needed now that this bug is fixed?

(In reply to Nicholas Nethercote [:njn] from comment #14) > vlad: is AutoCairoPixmanBugWorkaround still needed now that this bug is > fixed? Oh wait, I think the code you added to fix this ended up being modified into AutoCairoPixmanBugWorkaround? But if I remove AutoCairoPixmanBugWorkaround the test seems to work fine, so maybe it can now be removed...

> But if I remove AutoCairoPixmanBugWorkaround > the test seems to work fine, so maybe it can now be removed... See bug 1231888.

(In reply to Nicholas Nethercote [:njn] (on PTO until January 4th) from comment #15) > (In reply to Nicholas Nethercote [:njn] from comment #14) > > vlad: is AutoCairoPixmanBugWorkaround still needed now that this bug is > > fixed? > > Oh wait, I think the code you added to fix this ended up being modified into > AutoCairoPixmanBugWorkaround? But if I remove AutoCairoPixmanBugWorkaround > the test seems to work fine, so maybe it can now be removed... Is the work around being triggered if you leave it in?

> Is the work around being triggered if you leave it in? I'll continue this discussion in but 1231888.