133261 - Optimize the background Tiling

Status: RESOLVED DUPLICATE of bug 148598

(Core :: Layout, defect, P1)

Description

[dcone (gone)]

Windows Patblt seems to cause more problems than is solves, I think the thing to 
do to increase the performance would be.

1.)  Use the progressive doubling algorithm.. and cache any tiles that we make 
with the nsImage.  The slowest part of the algorithm is the making of the larger 
tiles.. and I think if we cached these.. all our speed issues would go away.

2.)  Don't use the PatBlt at all.  Seems to have some issues with drivers and 
speed on platforms.

Comment 1

[Christine Hoffman]

Changing QA contact

Comment 2

[dcone (gone)]

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

Comment 3

[dcone (gone)]

Attachment: Patch that gets rid of the patblt.. and optimizes the doubling algorithm.

Comment 4

[Kevin McCluskey (gone)]

With the patch installed I see problems rendering:
http://espn.go.com/mlb/news/2001/0927/1255952.html. Black lines appear in the
middle of page. If I reverse the patch and rebuild. It displays properly.

Don, thanks for cleaning up this code could you do a little more cleaning while
were at it?

0. Need a comment at the beginning that explains why we can't use the gdi patblt
call, so others will not go back and re introduce the patblt call.

1. Remove the extra semi-colon at the end of this line
+  PRInt32 x0,y0,x1,y1,x,y,width,height,canRaster,TileBufferWidth,TileBufferHeight;;

2. Change TheHDC to theHDC. Local variables should start with lowercase letter

3. If creating the tmpBitmap fails you should display a NS_WARNING and put a
comment in that you fall through to the draw a single tile at a time code. 

if(0 == tmpBitmap){
      ::DeleteObject(memDC);

4. This needs more explanation
  // see if the memory needed to do a progressive tile is available
  if ( (mAlphaDepth < 8) && (canRaster!=DT_RASPRINTER) &&
(256!=mNumPaletteColors) &&
(4*imageScaledWidth*imageScaledHeight)<MAX_BUFFERSIZE ) {

  It should mention that we will only tile into an offscreen if the tile is less
than 1/4 size of the buffer. If the tile is larger than that it is just as fast
to just blit it directly without going to temporary offscreen, 
  

5. Could you change aTileRect to aDestRect. It's referred to as the destination
rect in the calling code and I keep getting
aTileRect confused with actual size of an individual tile. 

aTileRect -> aDestRect
tileWidth -> destWidth;
tileHeight -> destHeight;

For the temporary buffer used for tiling could you change the prefix for the
names from Tile to Tiling. Again, It easy to confuse a single tile with the
entire temporary tiling buffer.

TileBufferWidth -> TilingBufferWidth
TileBufferHeight -> TilingBufferHeight

6. MAX_BUFFERSIZE is also a little to generic it should something like
MOZ_MAX_TILING_BUFFERSIZE


7. Could you replace the commas (,) with (;) colons at the end of the following
statements
destScaledWidth  = PR_MAX(PRInt32(mBHead->biWidth*scale), 1),
validX = 0,
validY = 0,
validWidth  = mBHead->biWidth,  


Thanks!

Comment 5

[dcone (gone)]

Attachment: newest patch.

Comment 6

[dcone (gone)]

Attachment: test image

Comment 7

[dcone (gone)]

Attachment: test image

Comment 8

[dcone (gone)]

Attachment: 2000x2 background tiling test

Comment 9

[dcone (gone)]

Attachment: 2x2000 background tiling test

Comment 10

[Phil "clef" Sweeney]

A checkin on the 16th or 17th to the trunk has caused a major 
performance hit on scrolling/rendering pages on my system (Windows XP).  Recent
earlier nightly builds have no problems.

Examples of the problem:

http://www.aintitcool.com/
http://whirlpool.net.au/

Testcase showing the problem clearly:

http://members.optushome.com.au/clef/mozilla/pa/

^^ this was a testcase that was solved with the patblt changes last month.  It
has now regressed and is horribly slow (100% cpu).

I narrowed down the nightlies between which the checkin occurred:

2002-04-16-06 2002041603 GOOD
2002-04-17-17 2002041710 BAD

The latest 1.0 branch nightly does not have the problem I believe.

This makes alt-tabbing between affected sites incredibly slow too. 

Comment 11

[dcone (gone)]

Attachment: Final pass at the progressive tile patch.

Please anyone and everyone apply this patch.. see if your slowness goes away. 
Post to this bug your results.	Thanx

Comment 12

[dcone (gone)]

Attachment: Updated patch. (never say final)

There is no limit on the size of the buffer created with this patch.  Failure
of progressive double will do the slow blit.

Comment 13

[Randell Jesup [:jesup] (needinfo me)]

Un-futuring.  If this gets into trunk soon and looks good, it might be
considered for RC2 (maybe) because of the wildly varying perf on win32 platforms
now.

Comment 14

[Kevin McCluskey (gone)]

Don: Can you update to the tip and repost your patch? I have a fresh pull from
today and I can not apply attachment id=80071. Thanks!

Comment 15

[dcone (gone)]

Attachment: patch that works with latest..

Comment 16

[Mark Annand]

Build Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0+) Gecko/20020508
on Win 2k and a circa 450mhz pentium.

Something's regressed Mozilla's performance with this site:

http://www.bathspa.ac.uk/igf/

Page has a tiled background image and also a 'fixed-relative-to-viewport'
background to some page elements.

What happened until the 'last week or three': the page scrolled well.

The problem now: scrolling the page is dramatically changed, very processor
intensive, and 'laggy'. If 'setiathome' is running in the background this
exacerbates the effect.

Comment 17

[Warner Young]

Found this bug while looking for why pages on thinkgeek.com seem to be scrolling
slowly.  Seems to be a very tall and thin background image that's repeated a
lot, so I'm guessing it's this bug.

Comment 18

[cartman]

Somebody pls change the OS to ALL same issue on Linux.

Comment 19

[Jaime Rodriguez, Jr.]

Nominating for nsbeta1, as this is perf issue, we should take a look at for the
next release.

Comment 20

[Jerry Baker]

For some reason, these test cases do not show how bad the problem is. I think
the images are not as large as commonly run into for reporters of this bug. Even
a 1kb 100x4000 PNG makes pages nearly unusable.

Will attach test case.

Comment 21

[Jerry Baker]

Attachment: Background image to use

Comment 22

[Jerry Baker]

Attachment: HTML showing horrible scrolling problem with a 273 byte PNG

Comment 23

[Julo]

Does this still appear after fixing bug 148598 ?
I don't see any problem with last testcase.

Comment 24

[Mike Palumbo]

Verifying problem with attachment in Comment #22.  As soon as the background PNG
loads, scrolling goes from *very* quick to unbelievably choppy and slow. 
Testing on Win2k, Moz 1.1b Build 2002072104.  
I'll have to try this one out under 1.0 in Linux & Windows later today.

Comment 25

[Jerry Baker]

2002073118 trunk shows great improvement on last test case.

Comment 26

[Amarendra Hanumanula]

 Scrolling is really fast on branch build: 2002-08-05 on WIN2K. Performance has
improved a lot on the given testcases.

Comment 27

[Mike Palumbo]

Using build 2002080704 on Win2k, still showing noticeable slowdown on test
cases.  Slightly faster than the 1.1b "offical" release, but definitely still a
lag for me.

Perhaps I should try the 20020805 build, to test for possible regression?

Comment 28

[Jerry Baker]

It is definitely worse in 2002080614 than in the last build I had (20020804).
The problem is back.

Comment 29

[Jerry Baker]

Ah. Changes that had improved performance were backed out on 08-02. See bug 148598.

Comment 30

[dcone (gone)]

I am gonna duplicate this against 148598 because I am addressing these issues
there.  

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