Closed Bug 102321 Opened 23 years ago Closed 22 years ago

ESPN's new page layout is dog slow in mozilla

Categories

(Core :: Layout, defect, P1)

All
Windows 2000
defect

Tracking

()

VERIFIED FIXED
mozilla1.0

People

(Reporter: mscott, Assigned: saari)

References

()

Details

(Keywords: regression, topembed+, topperf, Whiteboard: [adt1 rtm])

Attachments

(4 files)

ESPN recently came up with a new page layout for espn articles. I included a
link for one such article showing the new layout. 

When viewing the page, note the blue and black pixel border starting near the
top, going across the screen and then forming a vertical border down the right
hand side of the screen.

I think they are using small image tiles that are repeated although someone who
knows how to interpret this stuff will probably be able to figure out what
exactly they are doing.

The downside of this new page layout is that these little images are causing
HUGE performance problems with mozilla. I'm running on a 1.5GHZ win2k box with
todays (9/28) build. 

1) Try making your window wider. Note the multi-second delay before we repaint
2) Try switching focus to another mozilla window and moving that window on top
of the espn window. Note it takes a couple seconds before you can really start
dragging the top level window over. 
3) Try scrolling the page back and forth. Note it seems like the scrollbar is
"fighting" you to scroll. The repaints appear to be keeping you from having a
smooth scrolling experience. 

4) Try changing the focus back and forth between the espn window and another
window. Note the long delays before the window comes up to the front.

It's very unforunate that ESPN changed their page layout to use these tiny
tiling images just before we're about to ship a product. I hate to think what
this performance behavior is going to be like on a more normal machine. =(
adding the perf keyword. Is there a top site keyword to add as well?
Keywords: perf
it's definetly the blue and black tile images they are using for the right hand
border that's causing the problem. If I make the window wider so more tiling is
exposed on the screen the performance degrades dramatically. 
Build 2001-09-28-03 on Windows 98 SE (on a very old 200MHz Pentium Pro machine)
I don't see any performance problem on this site.
I don't notice the performance problem either, 10-1 CVS build.
Hmmm. Still having problems on my 1.5GHZ machine using BUILD ID: 2001100103, win2k.
Blocks: 71668
I have 10-22 cvs release build on WINNT and it loads quickly on 750Mhz machine
with cable modem connection.
Target Milestone: --- → mozilla0.9.7
weird, my machine at home is a 450 MHz and I don't see the problem. I only see
it here at work on my 1GHz machine. Well let's not waste time on this since it
sounds like I may be the only one seeing this. 

Wanna mark this as WFM Marc? I won't be offended =).
OK, I tried my Mac (g4 500) and Linux (P3 500) and they are cool - marking WFM -
no offense! ;)

mscott, please just add a comment with your video HW info for later tracking -
thanks. Also, does it improve if you disable image loading (I imagine it will).
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
*sigh* I don't know why this bug just plagues me. So I still see it on most of
ESPN's websites which have those small background images. I fired up quantify
and tried scrolling around one of the pages which is so slow for me. 

Turns out 97% of the time was spent in a windows routine called StretchDIBits.
caused by 318 calls to nsImageWin::DrawTile.

I'm going to re-open this bug now that I've done some analyis. However I don't
think I should be bothering Marc with this bug. Quantify is clearly pointing at
these little tile images as the culprit which has nothing to do with core layout
functionality IMHO.

Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Marc, mind if I reassing this to Pavlov? 

The new URL I used under quantify was ESPN's baseball signing rumors page
(although just about all the new pages they have show the problem):
http://espn.go.com/mlb/mlbrumorcentral2001.html

My test under quantify was starting at the top and scrolling half way down the
page. The wider your browser window the more of these tile images you get and
the slower we get when I scroll.

Win2k, 1.5GHZ, nVidia GeForce2 GTS/GeForce2 Pro. True Color (32 bit), 1280 x
1024 pixels.
Keywords: nsbeta1
More spam....disabling image loading did not fix the problem because the the
black and blue tiles are still downloaded even though the larger images on the
page are not. 

over to pavlov for real this time. I meant to do it last time. 
Assignee: attinasi → pavlov
Status: REOPENED → NEW
er, wasn't this going to be marked worksforme?

looks fine for me over a modem on win2k.

mscott: upgrade your video drivers (www.nvidia.com)
Status: NEW → RESOLVED
Closed: 23 years ago23 years ago
Depends on: 104999
Resolution: --- → WORKSFORME
Target Milestone: mozilla0.9.7 → ---
I have the latest drivers that came out on 12/03.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
*shrug*  maybe may patch for 104999 will fix this for you
Target Milestone: --- → Future
On a hunch, I turned hardware acceleration (Display -> Settings -> Advanced ->
Troubleshooting) down one notch.  I made a simple testcase with that background
(with width: 1600px so I can scroll horizontally) and a little text for vertical.

I compared the speed of both horizontal and vertical scrolling with full
acceleration, and one notch down from full.  Maybe it's my imagination, but the
lower acceleration seemed about twice as fast.  It wasn't as jerky.  It's hard
to notice vertical, as it's pretty fast there, but horizontal scrolling jerks
when you move the mouse quickly from side to side.

Now let's take a look at this lower acceleration level's description: "Disable
cursor and bitmap accelerations.  Use this setting to correct problems with the
mouse pointer, or to correct problems with corrupt images."

Now, I know Mozilla stores images in video memory, and uses hardware blits to
draw whenever possible.  The way this is being done is probably inefficient for
the hardware.  The processor doesn't go through expensive state changes and all
that.

I figure horizontal scrolling is slower because even scrolling one pixel
requires a paint command to redraw each tile.  Vertical scrolling only has to
repaint tiles that have newly moved onto the screen.

Anyway, can anyone reproduce this speed difference between full acceleration and
full-1?  My system is:
Win2k SP2, Celeron 500, 448MB RAM
GeForce 1 SDR, 23.11 drivers, DirectX 8.1, 800x600 32 bit, maximized mozilla window.
Wow that's an incredible deduction. Turning my harward performance from the MAX
down to about 1/2 way (disable all directdraw and direct3d accelerations) and
the performance problem is completely gone. it scrolls faster than IE on the
same page. Heck the entire browser is screaming now. I can't believe how fast
espn pages are loading right now. 

This is bizzare. What made you think to try turning that down? Why is mozilla
effected by that setting but not IE I wonder....
I've done some stuff with DirectX (in Visual Basic!).  I've done some
performance tuning.  Video hardware is designed for the big stuff.  It spends a
considerable amount of time preparing a task, so when it comes time to do it, it
gets done really fast.  When the task is small, but the setup is still large,
this can hurt performance.  What's even worse is when you send a series of
similar commands to the video card, and do the setup before each one even though
you only need to do it once.  So hardware acceleration was my first suspect.

Actually, just now I checked out some code and found this:
http://lxr.mozilla.org/seamonkey/source/gfx/src/nsRenderingContextImpl.cpp#161
// slow blitting, one tile at a time.... ( will create a mask and fall into code
below -next task-)

It falls back on slow code when there's an alpha channel.  Remove that from the
GIF, and it's blazing fast.
Any news on that?
Bug 122996 seems to be related to this.
Keywords: mozilla1.0
original URL appears to be fixed, 2002-2-21-03 w2k, probably bug 122996, also
bug 98252 (in 0.9.8) has contributed to tiling and fixing several problems with
scrolling.  not seeing any slow scrolling anymore on many bugs.  Please confirm,
Thanks.
Keywords: mozilla1.0+
Keywords: mozilla1.0
yeah, this was fixed between my changes and dcone's tiling changes
Status: REOPENED → RESOLVED
Closed: 23 years ago22 years ago
Resolution: --- → FIXED
my bad, this bug is not actually fixed. Re-opening. I told Pav it was but I
cranked up my hardware optimizations without rebooting. Now that I have
restarted my machine this problem is back.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
On what build and URL?  What video card?  The performance problem was fixed for
me.  Scrolling is nice and fast at that ESPN URL in both a nightly from a few
days ago and the 0.9.9 release.
on the same test url I posted under the url field. Video card details are
already listed under comment #10.

Build ID: 2002030908.
Regression:  Build 2002031803 is showing this performance problem, but 0.9.9 is
not. (I retested 0.9.9)
This is a serious performance problem affecting many websites.  It should
probably be fixed for 1.0.
I agree. The new perf issue is definetly a regression. It was fixed for a while
now ESPN is dog slow again. Can we look at re-triaging this?
Target Milestone: Future → ---
major sites, nominating topembed.
Keywords: topembed
over to dcone.  he has been playing with the windows image tiling code recently.
 perhaps he can shed some light on this.
Assignee: pavlov → dcone
Status: REOPENED → NEW
WFM: Scrolling is fine for me using cvs trunk 3/25 build on WinXP on 750Mhz athlon.
topembed+ 
till we confirm there is no problem here
- triage team (chofmann, cathleen, marcia)
Keywords: topembedtopembed+
Kevin, did you follow the steps in the bug and crank up your video card's
performance accelerators to the max? This bug happens on certain video cards.
Are you using one of the ones that causes the problem? 

nVidia GeForce2 GTS/GeForce2 Pro. True Color (32 bit), 1280 x
1024 pixels.

The problem goes away if I tone down my video accelerators by setting it to:
disable all directdraw and direct3d accelerations
I can see some slowdown scrolling this page, its chunky but not unusable.  The 
problem is the patBlt, seems video cards  support this windows calls in 
different ways.  My card at work for example.. wide, narrow tiles or very 
small tiles blit very fast, but slightly largers tiles that have the same width 
and height slow down.  My card at home flies on all size tiles.. thats a GForce 
II card.. and I see no problems.On windows 98 and some drivers.. patBlt will 
crash the system and that is a know windows bug.. they say to solve by 
reinstalling the correct drivers.  I have a bug open to fix all these problems 
by taking out this patBlt use the progressive doubling for our blits and cache 
the larger tiles that are created with the original nsImageWin object.
I can duplicate this on my laptop.  The following page:
http://www.tivo.com/discover/ displays horribly slow on my Dell laptop with the
Nvidia GeForce 2Go video hardware (it pegs the CPU).  Turning down the
performance setting such that the hardware acceleration is disabled makes the
page display like normal.

Seems to be something with hardware acceleration on certain cards no?
I would totally agree with your results.... thats what I am seeing.
bug 133261 includes a patch which completely removes the calls to the gdi patblt
on WIN32. This should also fix this bug. patblt seems to be unreliable. On some
graphics cards its fast. On others its very slow (depending on the level of
acceleration) The fix in bug 133261 uses progressive doubling of the tile into
an offscreen tiling buffer to make the rendering of tiled images fast instead of
relying on the gdi patblt call.
Depends on: 133261
nsbeta1+. 
Keywords: nsbeta1nsbeta1+
Priority: -- → P1
Whiteboard: [adt1]
Target Milestone: --- → mozilla1.0
Comment on attachment 80474 [details] [diff] [review]
Patch to take out the PatBlt.. use progressive tiling most of the time.

I think you want to change the value it used to determine if it needs to use
the progressive doubling algorithm from 3 tiles to at lease 8 tiles. The
overhead of progressively blitting the tiles to an offscreen then blitting it
back to the window is probably higher than the cost of just blitting the 8
tiles to directly.

  // if alpha is less than 8,not printing, and not 8 bit palette image then we
can do
  // a progressive tile and the tile is at least 4 times smaller than the area
to update
  if ( (mAlphaDepth < 8) && (canRaster!=DT_RASPRINTER) &&
(256!=mNumPaletteColors) && 
	  (numTiles > 3) )  <== change this from 3 to 7 {

I can notice a lag when scrolling
http://members.optushome.com.au/clef/mozilla/pa/using 
but when I change it from 4 tiles to 8 tiles as the progressive doubling
threshold the lag disappears.


r=kmcclusk@netscape.com.
Attachment #80474 - Flags: review+
*** Bug 135626 has been marked as a duplicate of this bug. ***
*** Bug 138034 has been marked as a duplicate of this bug. ***
*** Bug 138948 has been marked as a duplicate of this bug. ***
*** Bug 138822 has been marked as a duplicate of this bug. ***
*** Bug 139442 has been marked as a duplicate of this bug. ***
*** Bug 139445 has been marked as a duplicate of this bug. ***
*** Bug 131194 has been marked as a duplicate of this bug. ***
Comment on attachment 80474 [details] [diff] [review]
Patch to take out the PatBlt.. use progressive tiling most of the time.

sr=attinasi
Attachment #80474 - Flags: superreview+
adding adt1.0.0-.  Please get this into the trunk and let's look at this for rtm.  
Keywords: adt1.0.0-
Whiteboard: [adt1] → [adt1 rtm]
fixed on the trunk..please test this since I dont have any of the graphics cards 
that cause this.  I did some tests to make sure things dont slow down beyond 
what I have.. but I have not seen the really bad behavior.  Thanks
Status: NEW → RESOLVED
Closed: 22 years ago22 years ago
Resolution: --- → FIXED
Fixed for me. (GeForce2MX)
I have mixed results.

http://www.aintitcool.com/ is fixed
http://whirlpool.net.au/ is NOT fixed
http://members.optushome.com.au/clef/mozilla/pa/ is NOT fixed

I'm running build 2002042403.  This should incorporate the changes right?
I need one additional thing for Phil's changes.. let me get that in today.. then 
retest Phil.  The patch I put in did not fix the comment Kevin made about the 
size.. so that needs to get in for some of the larger backgrounds.  Give me one 
more day (checkin).. and this should be fixed.
Re-open until I get that last little fix  in.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Another site that is not fixed yet is http://www.devx.com/

Hopefully the new patch will fix it as well.

Jake
Ok.. checked in.. now go ahead and re-check everthing next build you get.  
Thanks.
Status: REOPENED → RESOLVED
Closed: 22 years ago22 years ago
Resolution: --- → FIXED
FYI: I tested all of the URL's in this page and all of the dups. The only one
that is slow scrolling on my machine is http://www.devx.com/. Although my
machine is not a very good test because I was not seeing the original slowdown
due to the patblt performance issue with some cards. This at least shows that
the new patch does not cause a slowdown for machines which were not seeing the
original problem.
I could add that, in my rather aged system (K6-III/400, Voodoo 2000, Win2K/SP2),
http://members.optushome.com.au/clef/mozilla/pa/ is still not scrolling smoothly
(but it's usable). IE6 behaves extremely smoothly.
Instead of making this bug a meta for image tiling performance problems, why
don't we open a new performance bug for tiling performance on Win32?
Unfortunately, bad news. On the latest trunk nightly (2002042510), all 3 of the
pages are back to being 100% CPU and slow. (aintitcool, whirlpool and
clef/mozilla/pa/).
The latest 1.0 branch nightly still does not have this regression.  Why can't we
just back out the code that caused it on the trunk?  Or is it more complicated
than that?
Filed bug 140236 for the problems mentioned in comments #56, #57, #58 (and one
more url).
I don't understand something..

The branch has the original regression in it.  It was the build that had all the
problems with the patBlt started on.  
So I took out the patBlt for the trunk.. and did a progressive doubling, now
that is not as fast as a patBlt(on machines that support this), but it also does
not exibit the bad behavior of patBlt on machines that dont support this.  All
this was done on my machines that I could not reproduce any slowness.. just on
reporters comments.  So now after I put in this fix.. your telling me that the
branch (I am assuming the 1.0 branch) never had this problem.  I started this
work based on the problems the 1.0 branch was having, that I could never
reproduce but I was told there was a problem.  How slow is slow.. for you, is it
un-usable.. or just a tad chuncky.  The regression I am tryin to fix it the 1 to
2 seconds before it updates.. unusable.. not the  .. it does not scroll as
smoothly as IE.
This has always been my position.  I filed a bug describing the TRUNK regression
between 16-17 April.

http://bugzilla.mozilla.org/show_bug.cgi?id=138948

Before this date, the scrolling all my listed pages (whirlpool, aintitcool,
/clef/mozilla/pa and ben's blog http://www.silverstone.net.nz/weblog/) is
SMOOTH.  After that date, it is slow, and on the mozilla/pa one and ben's blog
it is 1-2 seconds between screen updates (the others are less severe).

Therefore, there is a checkin during that period that caused a severe regression
on the trunk.  The branch is still scrolling smoothly (last checked yesterday).
With my fixes in.. and no PatBlt. on my NT 4.0 400 mhz machine, my 1.5 ghz
gforce II nvidia 64 meg w2k and my 300 mhz windows 98 AllinWonder.. I get good
scrolling.. meaning, meaning it takes lets that a second to scroll from top to
bottom.  My 1.5 ghz is very smooth.  My Nt 4.0 has a little chunkiness.. but not
bad.  My Windows 98 is very fast.

Ok.. so if you are having a problem.. there are a few things you need to tell me.
1.)  Web site, operating system, speed of computer.
2.)  Speed of scroll. 
     Unusable -- 2 second for each update.
     Hard -- 1 second updates.
     Chunky -- scrolls, but the scroll bar moves in chunks.
     average -- works.. very little chunky
     smooth -- scrolls smoothly.. can see any chunck movment.
     
3.)  If you have a GForce II card.. what are your optimization settings.
     on my I have a Hardware Acceleration slider under trouble shooting.  I can 
     set this anywhere from 0 to 6.  6 is full acceleration.  I dont get any 
     difference at all.

4.)  If you have a GForce II card.. try the same test with your settings for 
     acceleration changed.  What happens.

5.)  Only do 3 or 4 if you are having extreem difficulties.

I have tried on 4 different computers, and can not duplicate any of this extreem
slowness.  I have seen some chunky after I took out patBlt and did get extremly
bad with patBlt on windows 98.  But now.. all computers are usable.  
Last thing.. if any of you having problems.. can do a build.. that would help
alot.. I have some experiments I want to try using optimized bitmaps, like a one
line change.. and we could see if we get any difference.
Open until I can figure out what is going on.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
*** Bug 140236 has been marked as a duplicate of this bug. ***
pulling off of the 1.0 RC2 list.
No longer blocks: 138000
Keywords: mozilla1.0+mozilla1.0
2002042606 (latest RC1), Win2K, GForce2 MX, Athlon 800, 512 MB RAM.
nVidia drivers 28.32 (released 4/26)

full acceleration.
http://espn.go.com/mlb/news/2001/0927/1255952.html - chunky to hard
http://members.optushome.com.au/clef/mozilla/pa/ - smooth
http://www.tivo.com/discover/ - smooth
http://www.aintitcool.com/ - smooth
http://whirlpool.net.au/ - smooth
http://www.swva.net/ - chunky to hard

accel at -1
http://espn.go.com/mlb/news/2001/0927/1255952.html - average
http://members.optushome.com.au/clef/mozilla/pa/ - smooth
http://www.tivo.com/discover/ - average
http://www.aintitcool.com/ - average
http://whirlpool.net.au/ - smooth
http://www.swva.net/ - average

accel at -2: same as -1

Same as above, but with 2002042703 (latest trunk)

full acceleration.
http://espn.go.com/mlb/news/2001/0927/1255952.html - average
http://members.optushome.com.au/clef/mozilla/pa/ - chunky
http://www.tivo.com/discover/ - couldn't connect
http://www.aintitcool.com/ - average
http://whirlpool.net.au/ - couldn't connect
http://www.swva.net/ - smooth

accel at -1
http://espn.go.com/mlb/news/2001/0927/1255952.html - slightly chunky
http://members.optushome.com.au/clef/mozilla/pa/ - slightly chunky
http://www.tivo.com/discover/ - couldn't connect
http://www.aintitcool.com/ - average to slightly chunky
http://whirlpool.net.au/ - couldn't connect
http://www.swva.net/ - average

accel at -2: same as -1

All tests use the mouse wheel, since the arrow/scrollbar arrows don't move the 
page quickly enough to really tell one way or another.
Also, went back to full accel, and the mozilla/pa/ test site was only
average to slightly chunky.  Tried again after reboot, and it went back to
being chunky.
Blocks: 21762
OK, I'm sick of this bug. It's affecting too many web pages (not least of which,
my own!) 

Asa told me to make this a smoketest blocker. 
Severity: major → blocker
Keywords: smoketest
how.. can this be a blocker.. thats totally not fair.  I think I did the
responsible thing opening this bug so everyone knows that its high on my radar..
being sick of this bug is not a reason to make it a blocker.  It has not
regressed.. at all.

I reopened this until I could make sure that it did 
not regress..which it has not  The branch may have the problem,  although some
cases might be faster.. there are cases that are ALOT slower..and unusable.  The
PatBlt that is in the branch causes problems on some graphics card.. thats a
problem.  The trunk does not have the patBlt.. which only gives us a chunky
scroll at worst case.. this has been the way its been for about 2years.  Only
recently has the patBlt gone in.. and that caused a bunch of problems.

From what I can tell.. with the new code.. we are at worst case.. chunky.. which
is alot better than not usable like we were before.  I am just trying to get a
handle on what our problem is here.  From what I can tell.. we have this situation..

1.)  PatBlt (not in this build)-- can cause problems on windows 95, 98 and on
some GForce II cards (not the one I have).
2.)  The optimization for nsImage that was turned off a while ago.. and not
turned on for the background tile.. may be the culprit for chunky.. but at this
moment I can not test this because I can not reproduce any of the cases on my
machine.
3.)  This bug seems to only happen on some machines.. non-of which I have.. but
I keep on looking for more machines to test.

I really dont think this is a smoketest blocker.  Its something that has been
happening on some pages for some time.  I think that the worst cases have
improved from not-usable to chunky.  That is a good thing.  I think I can
improve the performance to smooth on all cases.. I just need a machine that I
can get chunky scrolling, I can not find a machine like that   I am removing
that tag.. and if you think it deserves this tag please call me.. email.  I
think the fix we have is a good one.. and I would like to add 2 more things.. to
improve the chuncky cases (very few).  Optimize the bitmaps and some caching of
the tiles.  Until then.. this is plenty usable in my optionion.
Keywords: smoketest
Excellent news guys!

I do not see slow scrolling anymore!  Ben's blog, /clef/mozilla/pa,
whirlpool.net.au, aintitcool.com are all much better (if only slightly slower
than on the 17th April, but I imagine dcone's yet-to-come changes will fix that).
 
Trunk Build 2002042808 shows the improvement.  Build 2002042708 was still slow.

My guess is dcone's checkin for bug 134887 did it.  Thanks!
Argh I spoke too soon!  I closed Mozilla, opened it again and the problem
reappeared!

I just tried turning down my hardware acceleration one notch and it went smooth
again.  I think this may have been mentioned previously in this bug though.

Sorry for the spam all.
Guys, maybe there are two separate problems with tiled backgrounds?

Some time ago I've filed bug #138034 about scrolling performance degradation.
That bug was marked as a duplicate of this one, but after reading your comments
here it is obvious that it is caused by something else, as it it also happens on
Linux and is less severe. I'll reopen bug #138034 now, please take a look.
Severity: blocker → major
Can someone apply this small patch.. and see if it speeds up the slow test
cases they might have.	I can't test this because its a theory.. but it would
be very helpful if someone could as soon as possible and report the results.
saari said he has some ideas on this.
dcone, I applied the patch and did not see any improvement (winxp, tnt2).
Went through the same sites as David Smith on a Athlon 1.2 Ghz, 256 MB, KyroII
64, Win2k(sp2) on build 2002042908.  Here are my results:

full acceleration.
http://espn.go.com/mlb/news/2001/0927/1255952.html - chunky
http://members.optushome.com.au/clef/mozilla/pa/ - hard to unusable
http://www.tivo.com/discover/ - average
http://www.aintitcool.com/ - chunky
http://whirlpool.net.au/ - hard
http://www.swva.net/ - smooth

accel at -1
http://espn.go.com/mlb/news/2001/0927/1255952.html - average
http://members.optushome.com.au/clef/mozilla/pa/ - average
http://www.tivo.com/discover/ - average
http://www.aintitcool.com/ - average
http://whirlpool.net.au/ - chunky
http://www.swva.net/ - smooth

accel at -2: same as -1

Can someone apply this patch... see if things speed up.  I would try but again
I dont have a machine I can reproduce the problems.. so I am just trying things
that might help.
Just to be on the safe side, this is a patch for the trunk that needs to go in
that fixes some recent image performance regressions. I'm not certain this is
related at all, but worth a check.
Saari, THAT'S IT!  I applied your patch and the scrolling is SMOOTH (even
smoother than with acceleration turned down a notch before).  This fixes
whirlpool.net.au, aintitcool.com and clef/mozilla/pa for me.

Please try to get this on the trunk ASAP.  What is the bug # for that patch?
Thanks a lot!

dcone: I applied your patch but Mozilla crashed on startup.
I had to clobber and build when I applied my patch.. because of the new members 
in the nsImageWin.h file.  Anyway.. its good we found the problem.. seemed to be 
a palette problem.. and not an image tile problem.  Great news.  I still would 
like to get this caching in there... but the call to test this is no longer 
needed.
Also.. is this problem only in 256 color mode (8 bit)for a display..  or is this 
the product of the GIF's being dithered.  Was everyone who had this problem 
using an 8 bit display?
*** Bug 141147 has been marked as a duplicate of this bug. ***
this will affect everyone in every bit depth. Don, while we're here, you want to
review the patch? Checking it in on this bug is as good as any IMO
Comment on attachment 81771 [details] [diff] [review]
Another possible patch to try

r=dcone
Attachment #81771 - Flags: review+
Comment on attachment 81771 [details] [diff] [review]
Another possible patch to try

sr=jag
Attachment #81771 - Flags: superreview+
->saari
Assignee: dcone → saari
Status: REOPENED → NEW
*** Bug 141570 has been marked as a duplicate of this bug. ***
fixed
Status: NEW → RESOLVED
Closed: 22 years ago22 years ago
Resolution: --- → FIXED
petersen, could you please verify this fix so we can get adt checkin approval? 
thanks.
Keywords: fixed1.0.0
Verified on the May 22 trunk build (2002-05-22-08) under Windows ME.
verified
Status: RESOLVED → VERIFIED
Verified on May 19th branch (2002-05-19-05)under Windows ME.
Keywords: verified1.0.0
I found that my system has reacted very badly to the patch for this bug. 
I filed bug 149224 as a separate topic for investigation. Details there.
*** Bug 141570 has been marked as a duplicate of this bug. ***
No longer blocks: 21762
Blocks: 21762
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: