255648 - (nVidia Only) slow redrawing images w/1 bit alpha/transparency (StretchDIBits)

Status: RESOLVED FIXED

(Core Graveyard :: GFX: Win32, defect)

Description

[Rob van der Linde]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040810 Firefox/0.9.1+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040810 Firefox/0.9.1+

I have had this problem for quite some time now, with Mozilla 1.8a2, Mozilla
1.7, 1.7.2, Firefox 0.9, Firefox 0.9.3 and Firefox 0.9.1+

256 color images are extremely slow on my machine, and CPU usage goes upto 100%
if the page needs redrawing that contains 256 color images. This can be
demonstrated by the test site: www.dungeonsiege.com and then resizing the window
or dragging another window over top. chug... chug ... chuuuuuug. it's virtually
unusable like this.

I brings my 2.8Ghz P4 / 1Gb RAM / GeForce FX 5600 to it's knees.

This is using the latest NVidia drivers. I have tried at least 8 different
versions of the NVidia drivers, all the same. I run 1280x960 32 Bit screen
resolution...

I later on experienced the same problem on another machine with an Athlon 1800+
768MB RAM, considerably older NVidia drivers compared to mine, and a GeForce MX
440SE running 1024x768 32-bit true color resolution this time. Once again, 256
color images were so slow, it becomes virtually unusable.

I also performed some tests, and have come to the conclusion:

256 color GIF - SLOW
256 color PNG - SLOW
True Color PNG - FAST
True Color JPG - FAST

Note: The image does not necessarily have to be a "background" 256 color image,
or a "large" 256 color image, it happens if you simply have a page, with only a
centered 256 color images on it, using a simple <img> tag.

In all cases, re-saving the images as true color PNG's or JPG's will resolve the
issue.

Reproducible: Always
Steps to Reproduce:
1. Windows XP machine with GeForce based graphics? and preferably latest drivers.
2. Open www.dungeonsiege.com.
3. Resize browser window.

Actual Results:  
Resizing the page, on the specific platform/graphics card becomes extremely slow

Expected Results:  
Be as fast as if the images were true color images.

Comment 1

[Rob van der Linde]

I just tried an optimized P4 build for win32 (pigfoot's build) of FireFox 0.9+,
compiled in Visual Studio, and it does not have this problem, the Dungeon Siege
site with large 256 color GIF now redraws extremely fast!!! I think this would
need to be checked out.

Comment 2

[Rob van der Linde]

I have Done some more tests:

Another machine, Firefox 0.9.3, P4 1.8, GeForce 2 Ti has the same problem, very
slow, 100% cpu used, the user cannot use the dungeonsiege website properly
because of this slowdown.

Here is another test site: http://jls.geek.nz/pages/shoutbox/ (can barely scroll
- Opera/IE are fine)

This site could be fixed simply if the background image is resaved as 24-bit
rather than 256 colours.

I have another user with a Radeon 9000 graphics card, and this does NOT happen.
This confirms that this bug is trictly on NVidia graphics card - but this is a
very large market sector, so is important. It happens on a variety of NVidia
driver versions.

It sounds like it to me that the 256-color graphic is converted every time it
needs rendering. Maybe it would be better to convert it once, and keep it in
some sort of memory cache. This would greatly speed up rendering.

Comment 3

[Nickolay_Ponomarev]

Same here with 
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040917
Firefox/0.10 
and 
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a3) Gecko/20040817

I can reproduce this on www.dungeonsiege.com (switching from and to browser) and
by keyboard-scrolling this document:
http://www.mozilla.org/projects/embedding/PublicAPIs.html
(it is slow with self-made testcase too, the testcase is very trivial (just an
<img tag>+text), can attach on request). The slowness goes away if I convert to
PNG however. Ie:
256 color GIF - SLOW
256 color PNG - *FAST* (not slow)
True Color PNG - FAST

P4 2Ghz and Geforce2 MX

Since it is said to be fixed in pigfoot's builds (I didn't try myself), asking
for blocking aviary-1.0. I suffer from this (and maybe other image-drawing bugs)
a lot.

Comment 4

[Rob van der Linde]

I have later found out that it was not pigfoots build that fixes it entirely,
but it actually goes a little deeper than that...

it doesn't matter if you have pigfoots build, a standard build (Firefox 1.0 PR),
or any other build... but this is what I recently found:

- the slowness sometimes goes away. and sometimes comes back.

I can sometimes view sites like dungeonsiege.com normally. but this symptom is
rare, that it "suddenly" will start working fast again, most of the time it will
not work like that.

if the slowness bug has gone away like that (which like I said is rare), a
restart of the browser will usually kick it back into "slow mode".

256 colour pngs do go slow for me, www.latitudeiv.com startup page is a site I
did recently that uses a 256 colour png, where this happens. Maybe it didn't do
it on your test machine, because the bug appears to be partially "random" now.

like I said, this seems to go a little deeper then expected.

Comment 5

[Nickolay_Ponomarev]

ok clearing the blocking request, since no patch is available, and the bug
doesn't seem trivial.

I do see the bug with <http://www.latitudeiv.com/images/splash.png>, though I'm
not sure it is the same issue as what was originally reported. The PNG is
transparent here, and when I use IrfanView to remove transparency, the problems
goes away. Though the problem *also* goes away when re-saving a 256-GIF.

So if that helps, IrfanView does something to the input file, making the problem
goes away, when saving as. I withdraw my comment about fast 256 color PNG for now.

I'll attach two files from moz.org, original and re-saved by IrfanView. The
former shows the bug, the later is ok. From what IrfanView tells about these
files, the difference is that the first is "GIF - LZW, Transparent color: 4,
Interlaced" and the second is just "GIF - LZW". I'd like to see an image that
1) exhibits the bug.
2) does not have a transparent color.

If one cannot be found it is probably a dupe of oneof the transparency bugs.

Comment 6

[Nickolay_Ponomarev]

Attachment: a transparent 8-bit GIF showing the bug

Comment 7

[Nickolay_Ponomarev]

Attachment: not transparent GIF that doesn't cause problems with mozilla

Comment 8

[Ian Batterbee]

For anyone who hasn't already, it would pay to read the background info in bug
260676 which is related, and possibly a dupe, as I did some testing with the
standard microsoft PCI VGA driver on an nvidia card, and found no problem occurs
there.

This does seem to be a specific problem with 256 color images that have
transparency information with NVIDIA drivers. It does not seem to matter if the
image is a PNG or GIF, as long as it meets those three criteria.

For the page at http://jls.geek.nz/pages/shoutbox/ - the problem is mostly
caused by the transparent background image dark_background_dark.gif. If I save
that file locally and remove the transparency info, the problem goes away.

I suggest changing the summary of this bug to include the words 8bbp, nvidia,
and transparent to better describe it and assist people searching for it. I'ld
do it myself, but I don't own this bug.

Comment 9

[Nickolay_Ponomarev]

changing summary per comment 8. Not sure if it is a problem with transparent
images only. If it is, bug 260676 is a dupe of this.

Comment 10

[ArronM (:paper)]

*** Bug 278614 has been marked as a duplicate of this bug. ***

Comment 11

[ArronM (:paper)]

*** Bug 260676 has been marked as a duplicate of this bug. ***

Comment 12

[ArronM (:paper)]

nVidia is known for having very very slow StretchBlt calls.  One site even
hinted that some video card makers tried to optimize StretchBlt on-card, but
failed the WHQL certification, so they removed it.  Whether that's the case for
nVidia is speculation.  One thing is for certain, the nVidia video driver or
video card's bitmap accelerations routines are horrible.

Temporary solution:

Under "Display Settings"->Advanced->TroubleShooting, move the "Hardware
Acceleration" down one notch from "Full", which disables "cursor and bitmap
accelerations"


Real solution:
Hoping that nVidia fixes is unrealistic.  The only real solution would be to
stop using GDI (switch to DirectX, OpenGL, GDI+, etc).  

Or, possibly, grabbing the area of the screen, manipulating the bits ourselves,
and then doing a StretchBlt in SRCCOPY mode.  As opposed to what we do
currently, which is StretchBlt the alpha layer in SRCAND mode, then StretchBlt
the image layer in SRCPAINT mode.  But that solution would punish the good video
cards who implement StretchBlt correctly (and fast), if there are such video cards.

Comment 13

[ArronM (:paper)]

Wherever I said StretchBlt, I meant StretchDIBits.  Correcting title.

Comment 14

[ArronM (:paper)]

This bug is directly related to bug 228399, the regression bug being Bug 277762.

It appears using CreateDIBSection to create the surface instead of
CreateCompatibleBitmap slows down nVidia's optimization routines.

The patch currently in Bug 277762 fixes the speed problems shown on this and
dup'd bugs on my nVidia FX5500 card.

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

Comment 15

[Nickolay_Ponomarev]

[e-mail], how exactly this is a duplicate of a regression (from bug
228399) introduced no earlier than Nov 2004 on trunk? This bug was filed long
before, and the patch in bug 277762 was just a test patch, which doesn't look
like it's going to be checked in. The two problems may have the same cause, but
since the bug 277762 may be fixed without resolving that root problem (e.g.
backing out the patch that caused it), I'd avoid duping this bug to that.

Reopening, adding a dependency in case the fix for bug 277762 will also fix this
bug.

Comment 16

[ArronM (:paper)]

You're right.  Dependency makes more sense.

Correction to Comment #14 (I had the GDI names reversed):
It appears using CreateCompatibleBitmap to create the surface instead of
CreateDIBSection slows down nVidia's (on card?) optimization routines
(namely StretchDIBits).

In other words:
CreateDIBSection + nVidia StretchDIBits() = ok
CreateCompatibleBitmap + nVidia StretchDIBits() = slow painting

A bit of background:
When we create our drawing surface, we use CreateDIBSection if
NS_CREATEDRAWINGSURFACE_FOR_PIXEL_ACCESS flag is on, and CreateCompatibleBitmap
when the flag is off.

Even prior to the regression, NS_CREATEDRAWINGSURFACE_FOR_PIXEL_ACCESS flag was
not set for the main drawing surface.  The test patch in Bug 277762 turns on the
NS_CREATEDRAWINGSURFACE_FOR_PIXEL_ACCESS flag. So, you are right, while that
patch fixes this bug (for me), it may not be the end resolution of that bug.  If
they dump the test patch, I'll move it here.

If there's someone with this problem and can build mozilla, please try out the
patch.  If you aren't a builder, I'll see if I can put up a build with
CreateDIBSection.

Comment 17

[ArronM (:paper)]

Here's the build with forced CreateDIBSection.  Unzip it to a new directory,
close all mozilla windows, and run mozilla.exe.  Build ID should display on the
titlebar as 0000000000 since it's built on my computer.

http://mozilla.animecity.nu/builds/MozForceDIBSection050302.zip

Test it with the two GIFs.  Drag another window like crazy over top of the
image, and watch your CPU.

Comment 18

[Ian Batterbee]

I get two xpcom.eventreceiver unable to locate DLL gdiplus.dll errors, and then
stayed in memory but didn't open any windows... end-tasked it, and restarted, it
it only got as far as the mozilla splashscreen and hung.

I can't find said DLL's anywhere on my HDD

Comment 19

[ArronM (:paper)]

http://mozilla.animecity.nu/builds/GDIPlus.zip

For those who don't have gdiplus.dll, unzip to the location where the
mozilla.exe is (or anywhere else in your path).  GDIPlus is unrelated to this
bug, it's just that my build required it (as does SVG builds)

Comment 20

[Ian Batterbee]

Sorry I don't think I can help you, as I still just get the orange splash screen
and then it hangs.. I've left it for about 30 minutes and it got no further. 
Tried deleting my old mozilla profile, and uninstalled (the official) mozilla
completely, but no change.

Comment 21

[Nickolay_Ponomarev]

I don't have a trunk tree here, nor do I have enough bandwidth to download your
build. I modified Firefox 1.0 to use NS_CREATEDRAWINGSURFACE_FOR_PIXEL_ACCESS in
GetBackbuffer(). I don't have time for testing it thoroughly, but this indeed
fixes the problem with the attached file - before this change Firefox lagged for
~1 sec when Alt+Tabbing to it and dragging another window on top of it was very
sluggish, after the change, no visible lag, dragging another window over the
image may eat 100% CPU (if you drag it very fast), but it's no more sluggish.
(Celeron 2Ghz, Geforсe2 MX400, 32b color depth, full accel.)

Could someone explain to me what does bug 277762 comment 25 mean? Does this
change alone cause slowdown on non-transparent images?

Comment 22

[Rob van der Linde]

I tried the build with forced CreateDIBSection... 256 colour images were fine
with this build (e.g. fast)... except transparent images had a big black box
around them. I have a GeForce FX 5600

Transparent images with this black box around them can be seen if you go to the
help->about page (the Mozilla logo has a black box around it)

Also some of the toolbar icons have this same black box around them.

Comment 23

[ArronM (:paper)]

It appears I did something wrong when building, so the build in Comment #17 can
be ignored.

Thanks Nickolay for your testing.  From the looks of it, the patch slows down
non-transparent by almost 1/2, while speeds up transparent by 2 to 3 times.

Comment 24

[ArronM (:paper)]

Please try the latest nightly build (20050305)
http://ftp.mozilla.org/pub/mozilla.org/mozilla/nightly/latest-trunk/
or firefox latest nightly
ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/

(some of the mirrors may not have 20050305 as of me posting this)

Comment 25

[Nickolay_Ponomarev]

Great! should this be marked as a dupe of bug 284716?

Comment 26

[Rob van der Linde]

Great, I tried the latest build of Firefox: 20050306 and all sites that gave me
slowness problems before are now fixed. renders very fast now and no more
transparency glitches. thanks.