260676 - slow redraws occur when displaying transparent 256 color (8 bpp) images (nvidia only)

Status: RESOLVED DUPLICATE of bug 255648

(Core Graveyard :: Image: Painting, defect)

Description

[Ian Batterbee]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040803
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040803

The gecko engine appears to have trouble redrawing transparent images. I first
noticed that resizing the browser window while displaying a webpage I was
writing was unusally slow and jerky. Moving another app over the top of the
window resulted in similarly slow redraws.

I removed parts of the HTML one by one until all that was left was a single
transparent PNG file at around 700x300 pixels, 8 bit colour depth, and the
problem still occured.

This may be related to several other bugs that mention slow and transparent, but
they all seem to have been related to very old versions of mozilla, and have
either been closed, or unreproducable.

I have tested this in firefox 0.9.3 and mozilla 1.7.2, and have observed the
problem occuring with both transparent GIF and PNG files.

No HTML document is necessary - the image can be specified as the URL.

The images in question were created with paint shop pro 4.12, and in case it's
something to do with that, a sample slow image 

Reproducible: Always
Steps to Reproduce:
1. load a transparent gif or png into mozilla
2. resize the window, or drag another app over the top of the transparent image
3. watch things redraw really slowly.

Comment 1

[Ian Batterbee]

Oops one other thing - iexplore displays the same image quickly and resizes the
window without any issues at all.. so that rules it out being a video driver etc
problem

Comment 2

[Nickolay_Ponomarev]

I can see the bug with http://www.latitudeiv.com/images/splash.png and
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040917
Firefox/0.10

Can you post a link to a non-8-BPP image that causes slow downs?
See also bug 255648.

Comment 3

[Ian Batterbee]

Do you mean you *can*'t see it with that image ?

'cos I'm very confused now... I just opened that in moz 1.7.2 at home, and found
no problem with the redraw at all, so I went and look at the image I posted here
yesterday and the original script where I saw the problem and that's fine as well.

The thing is, I tried and observed this problem on several machines and OS's at
work beforing filing the bug.

As for a non 8bpp image... I don't know if it's a problem with paint shop pro or
not, but I've never been able to create a transparent PNG in anything but 8bpp -
I always assumed that it was only possible in 8bpp format.


Hmmm.. perhaps it IS a video driver problem (that doesn't affect IE).. I've got
an ATI card at home, and we've all got nvidia cards in the machines at work.

I better so some more testing.

Comment 4

[Ian Batterbee]

Hmmmmm after reading bug 25648 , it does seem like there's an issue with
transparency and the nvidia drivers.. can't recreate the problem at all with the
ATI9600 pro in this machine, yet I saw it on two differently configured Win2K
and one XP machine at work yesterday, all of which had nvidia cards in them.

Comment 5

[Nickolay_Ponomarev]

Yes, I see the problem on http://www.latitudeiv.com/images/splash.png

Commenter on bug 255648 supposed that this is not always reproducible, though I
do see it for quite a long time now. There's some data posted in that bug, and
the conclusion was that it only occurs with GeForce video cards. He experienced
that with various drivers versions (including the most recent from nvidia).

I believe that PNGs can be transparent and not 8-bit, though I don't know much
about that.

There's something wrong with current image drawing code (at least on
Windows+GeForce). We should find out what is the exact problem to help resolving
these issues.

To see if this bug and bug 255648 are different, we need a non-8 bit transparent
PNG image.

Comment 6

[Ian Batterbee]

Okay.. done some more tests on my work computer (win2k, geforce mx440)

I tried this with the colour depth set to 32/16/8 bpp, and although it did get
faster as the colour depth reduced (less data to push through the bus), the
problem was still there.

I then sacrificed the layout of my desktop icons and removed the nvidia driver
and rebooted. Windows came up with the standard PCI VGA adapter, and detected an
MX440, but I ignored the 'install new driver' dialog and left it running the
standard VGA driver. 

Changed resolution to 800x600 for sanity reasons, colour depth on 8 bit (only
available option with the standard VGA driver)

Started mozilla, opened the page with splash.png on it, and resized the window.
While I noted that moving the window around the desktop was awfully slow with no
hardware acceleration, resizing it was actually quite snappy, and showed no
indication of being sluggish on transparent images.

I then downloaded the latest (61.77) nvidia drivers from www.nvidia.com, ran the
installer, which wanted to reboot, did so, and windows came back up in 16 bit
colour. Retested, and confirmed that reinstalling the nvidia driver reintroduced
the problem.

Finally, I retested it in IE and confirmed that it still does not show any slow
down there.

Certainly looks like it's an interaction between mozilla and the nvidia driver
that is causing this problem.

As for non 8bpp PNG's...

will these do ?

http://www.webcolors.freeserve.co.uk/png/png-alpha-transparency.htm

they seem to resize okay on my work computer...  PSP 4.12 shows the two circles
in the middle right of the page as squares, so probably doesn't support that
sort of PNG file properly.

Comment 7

[Nickolay_Ponomarev]

Ok, confirming for now, if we'll find a non-transparent 8bpp image that causes
slowdown in bug 255648, this bug and that are different. Otherwise this is a dupe.

Comment 8

[Ian Batterbee]

My feeling is that the two bugs are indeed referring to the same underlying
problem. I've got no problem if you flag this as a dupe.

Comment 9

[ArronM (:paper)]

*** This bug has been marked as a duplicate of 255648 ***