Closed Bug 328380 Opened 18 years ago Closed 18 years ago

Bad scrolling performance with Cairo builds using large fixed positioned background-image

Categories

(Core :: Graphics, defect)

Product:
Core
Component:
Graphics
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: martijn.martijn, Assigned: vlad)

References

Details

(Keywords: perf, testcase, Whiteboard: [blocking1.9a1+])

Attachments

(5 files)

background image for testcase
4.85 KB, image/gif
Details
testcase
698 bytes, text/html
Details
benchmark result
1.73 KB, text/plain
Details
Bench Results 2
1.73 KB, text/plain
Details
patch for cairo win32, checked in to upstream as well
21.93 KB, patch
vlad
: review+
Details | Diff | Splinter Review 
See upcoming testcase, which I more or less borrowed from bug 90198.

With cairo builds I get a bad scrolling performance, with non-cairo builds, I get a normal scrolling performance.

    
    

    
  

      
      
      
      

        Attached file
          
        testcase
        — 
      

    


  
With the 2006-02-22 build (non-cairo) I get 4580ms for the scrolling test, cpu stays almost at 0%.
With the 2006-02-23 build (cairo) I get 13940ms for the scrolling test, cpu gets almost 100%.

    
  
Depends on: 328367

    
  
Flags: blocking1.9a1?

    
    

    
  
Can you try again?  In my 1.5 build I get 5708ms but in my debug cairo build from yesterday I get 4812.  Should be even better in an opt build...

    
    

    
  
Now using 2006-04-05 trunk builds, cairo and non-cairo.
Non-cairo build gives me 5007 ms
Cairo build gives me 15402 ms
So no improvement here.
I'm using a 800MHz Duron with a NVidia GeForce2MX 100/200 32MB, btw.


    
  
Depends on: cairoperf

    
  
Blocks: cairoperf
No longer depends on: cairoperf
Blocks: 334719
No longer blocks: cairoperf

    
    

    
  
I'm getting jerky/stuttering/intermittent scrolling on *all* pages. Another bug?

AMD 64 X2 3800+
1 GB RAMwi
ATI Radeon 1800 XT with 512 MB
Windows XP

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060805 Minefield/3.0a1

    
    

    
  
Peter, see bug 328367

    
    

    
  
Yep, just found it too (and had a mid-air collision with your comment) :-)

    
    

    
  
Maritjn, I have a patch that might fix this, but before we go there would you mind grabbing http://www.stardock.com/products/xpbench/ and letting me know what it says about the two accelerated alpha bits (on the main screen) and also your benchmark results?  (The program is a little quirky; it might look like it's hung every now and then but it fixes itself.)

    
    

    
  
FWIW, on my laptop, bonecho results in 6062ms on this with 0% cpu usage, and trunk+cairo results in 4730ms with 100% cpu usage.  Still looking into what the difference is.

    
    

    
  
I just checked in a potential fix for this in bug 343655; can you try tomorrow's build and let me know what you see?

    
    

    
  
With the 2006-08-09 build, I get: 6850ms
With the 2006-08-10 build, I get: 4076ms (and very important, no cpu load anymore)
So for me this bug is fixed. Thank you!
You still want me to do the things you mentioned in comment 8?

    
    

    
  
Nope, no need.  I think I know what's going on now.

I also now know that our Tp numbers for windows are basically worthless :(

Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED

    
    

    
  
Looks like it regressed (on cpu usage at least).
I average 28s with 100% CPU usage on a P4.
I don't know for sure why,but this tescase has always been very slowfor me.
I tested with recent trunk,recent trunk sse2,safe mode,new profile,Win XP,Win 2003 ... always the same results.
Although BenchJS or other tests are ok.
Scrolling speed is a really very slow.
Testcase takes ~ 6s with k-meleon 1.02.

See http://forums.mozillazine.org/viewtopic.php?t=467434 (pages 1 & 2).

    
    

    
  
I went back to Aug 9-10 builds to check this out.  I had saved the 2006080914 hourly build because that build was from between the two cairo checkins (bugs 342366 & 343655) for that day.  Here's what I found with the testcase in this bug.

2006080907 9-10 secs
2006080914 9-10 secs
2006081004 23-25 secs
and the testcase is still this slow with the current nightly.  

So the second cairo checkin which was bug 343655 made the testcase worse for me.

    
    

    
  
(In reply to comment #14)
> I went back to Aug 9-10 builds to check this out.  I had saved the 2006080914
> hourly build because that build was from between the two cairo checkins (bugs
> 342366 & 343655) for that day.  Here's what I found with the testcase in this
> bug.
> 
> 2006080907 9-10 secs
> 2006080914 9-10 secs
> 2006081004 23-25 secs
> and the testcase is still this slow with the current nightly.  
> 
> So the second cairo checkin which was bug 343655 made the testcase worse for
> me.
> 

You are right,just found an old sse2 build 
Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9a1) Gecko/20060809 Minefield/3.0a1 (bangbang023)
Testcase takes ~ 11s ,so it regressed.


    
    

    
  
I agree, I have a new computer now and with this computer, I get:
2006-08-09 build, I get: 6500ms (no cpu load)
2006-08-10 build, I get: 8200ms (100% cpu load)
With a 1.8.1 build, I get appr. 5000ms.
So apparently, on my older computer things have improved, but on my new computer, things have regressed (as for other users also):
Older computer is: 800MHz Duron with a NVidia GeForce2MX 100/200 32MB.
Newer computer is: 1.8GHz Centrino with a NVidia GeForce Go 7300 256MB
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

    
    

    
  
This apparently is graphics card dependent.  At home the test doesn't spike the CPU and takes 4 seconds.  I have a Radeon X300/X550 128MB.  At work which I noted above was much slower.  That machine has some older Nvidia GeForce with 64Mb.  Both machines have the same CPU speed -> 3 ghz.  

    
    

    
  
(In reply to comment #17)
Hmm not sure,I have an overclocked ATI 9800 (128 MB) and I noticed high CPU usage. 
But obviously,the faster your hardware is the faster the testcase will be completed.
I can test tomorrow with a Matrox PCI (4MB) if you think it will be any useful.
I'm pretty sure not every firefox user have such recent cards. ^^


    
    

    
  
I'm getting 100% CPU usage on both of my systems with the testcase page. One is running a FX5500 + Vista (~4000ms) and the other a X1800GTO + XP (~4700ms).

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9a1) Gecko/20060926 Minefield/3.0a1

    
    

    
  
Ok; I've written up a little benchmark that should give me a better idea of what's going on.  Could you guys download http://people.mozilla.com/~vladimir/misc/gdibench.exe and run it, and put the results in a comment here along with what your video card is?

    
    

    
  
(In reply to comment #20)
> Ok; I've written up a little benchmark that should give me a better idea of
> what's going on.  Could you guys download
> http://people.mozilla.com/~vladimir/misc/gdibench.exe and run it, and put the
> results in a comment here along with what your video card is?

Thanks a lot Vlad. Here are my results:


X1800 GTO, Catalyst 6.9, Windows XP

DC Caps (  ARGB DIB): SB_CONST_ALPHA SB_PIXEL_ALPHA BITBLT STRETCHBLT
DC Caps (   RGB DIB): SB_CONST_ALPHA SB_PIXEL_ALPHA BITBLT STRETCHBLT
DC Caps (   RGB DDB): SB_CONST_ALPHA SB_PIXEL_ALPHA BITBLT STRETCHBLT
OIL: ERROR liboilcpu.c 549: oil_cpu_detect_kernel_support(): Operating system is
 not known to support SSE.  Assuming it does, which might cause problems
                       DIB ARGB -> DIB ARGB BitBlt:        752 ms
                        DIB ARGB -> DIB RGB BitBlt:        655 ms
                         DIB RGB -> DIB RGB BitBlt:        239 ms
                         DDB RGB -> DDB RGB BitBlt:          1 ms
                         DIB RGB -> DDB RGB BitBlt:        776 ms
                        DIB ARGB -> DDB RGB BitBlt:        612 ms
              DIB ARGB -> DIB ARGB OVER AlphaBlend:        954 ms
                      oil RGB -> RGBA oil_rgb2rgba:        742 ms
     oil ARGB -> ARGB OVER oil_composite_over_argb:        947 ms
                   DIB ARGB -> DIB ARGB StretchBlt:        770 ms
                    DIB ARGB -> DIB RGB StretchBlt:        689 ms
                     DIB RGB -> DIB RGB StretchBlt:        235 ms
                     DDB RGB -> DDB RGB StretchBlt:          2 ms
                DIB ARGB -> DIB ARGB StretchBlt[2]:       1131 ms
                 DIB ARGB -> DIB RGB StretchBlt[2]:        774 ms
                  DIB RGB -> DIB RGB StretchBlt[2]:       2731 ms
                  DDB RGB -> DDB RGB StretchBlt[2]:         62 ms
               DIB ARGB -> DIB ARGB StretchBlt[2H]:       5152 ms
                DIB ARGB -> DIB RGB StretchBlt[2H]:       4755 ms
                 DIB RGB -> DIB RGB StretchBlt[2H]:       4581 ms
                 DDB RGB -> DDB RGB StretchBlt[2H]:       5735 ms


FX5500, Forceware v96.33, Vista x64

DC Caps (  ARGB DIB): SB_NONE BITBLT STRETCHBLT
DC Caps (   RGB DIB): SB_NONE BITBLT STRETCHBLT
DC Caps (   RGB DDB): SB_NONE BITBLT STRETCHBLT
OIL: ERROR liboilcpu.c 549: oil_cpu_detect_kernel_support(): Operating system is
 not known to support SSE.  Assuming it does, which might cause problems
                       DIB ARGB -> DIB ARGB BitBlt:       1219 ms
                        DIB ARGB -> DIB RGB BitBlt:       1000 ms
                         DIB RGB -> DIB RGB BitBlt:        562 ms
                         DDB RGB -> DDB RGB BitBlt:       1125 ms
                         DIB RGB -> DDB RGB BitBlt:       1094 ms
                        DIB ARGB -> DDB RGB BitBlt:       1188 ms
              DIB ARGB -> DIB ARGB OVER AlphaBlend:       2281 ms
                      oil RGB -> RGBA oil_rgb2rgba:       1079 ms
     oil ARGB -> ARGB OVER oil_composite_over_argb:       1218 ms
                   DIB ARGB -> DIB ARGB StretchBlt:       1219 ms
                    DIB ARGB -> DIB RGB StretchBlt:       1000 ms
                     DIB RGB -> DIB RGB StretchBlt:        563 ms
                     DDB RGB -> DDB RGB StretchBlt:       1109 ms
                DIB ARGB -> DIB ARGB StretchBlt[2]:        922 ms
                 DIB ARGB -> DIB RGB StretchBlt[2]:        844 ms
                  DIB RGB -> DIB RGB StretchBlt[2]:       3203 ms
                  DDB RGB -> DDB RGB StretchBlt[2]:        922 ms
               DIB ARGB -> DIB ARGB StretchBlt[2H]:       5921 ms
                DIB ARGB -> DIB RGB StretchBlt[2H]:       5282 ms
                 DIB RGB -> DIB RGB StretchBlt[2H]:       5172 ms
                 DDB RGB -> DDB RGB StretchBlt[2H]:       5843 ms

    
    

    
  
Thanks for your work vlad !

Radeon 9800* Windows 2003.
*not pro not se 

 DIB ARGB -> DIB ARGB BitBlt:       1609 ms
                        DIB ARGB -> DIB RGB BitBlt:       1360 ms
                         DIB RGB -> DIB RGB BitBlt:        219 ms
                         DDB RGB -> DDB RGB BitBlt:          0 ms
                         DIB RGB -> DDB RGB BitBlt:       4640 ms
                        DIB ARGB -> DDB RGB BitBlt:       1328 ms
              DIB ARGB -> DIB ARGB OVER AlphaBlend:       1641 ms
                      oil RGB -> RGBA oil_rgb2rgba:       1500 ms
     oil ARGB -> ARGB OVER oil_composite_over_argb:       1578 ms
                   DIB ARGB -> DIB ARGB StretchBlt:       1609 ms
                    DIB ARGB -> DIB RGB StretchBlt:       1360 ms
                     DIB RGB -> DIB RGB StretchBlt:        203 ms
                     DDB RGB -> DDB RGB StretchBlt:          0 ms
                DIB ARGB -> DIB ARGB StretchBlt[2]:       1344 ms
                 DIB ARGB -> DIB RGB StretchBlt[2]:       1656 ms
                  DIB RGB -> DIB RGB StretchBlt[2]:       6187 ms
                  DDB RGB -> DDB RGB StretchBlt[2]:        125 ms
               DIB ARGB -> DIB ARGB StretchBlt[2H]:       7641 ms
                DIB ARGB -> DIB RGB StretchBlt[2H]:       6828 ms
                 DIB RGB -> DIB RGB StretchBlt[2H]:       6578 ms
                 DDB RGB -> DDB RGB StretchBlt[2H]:      10875 ms

    
    

    
  
Saphhire Radeon 9200 Atlantic, Win XP Pro SP2, 512 MB RAM, 4 Programs running:

OIL: ERROR liboilcpu.c 549: oil_cpu_detect_kernel_support(): Operating system is
 not known to support SSE.  Assuming it does, which might cause problems

DC Caps (  ARGB DIB): SB_CONST_ALPHA SB_PIXEL_ALPHA BITBLT STRETCHBLT 
DC Caps (   RGB DIB): SB_CONST_ALPHA SB_PIXEL_ALPHA BITBLT STRETCHBLT 
DC Caps (   RGB DDB): SB_CONST_ALPHA SB_PIXEL_ALPHA BITBLT STRETCHBLT 
                       DIB ARGB -> DIB ARGB BitBlt:       2180 ms
                        DIB ARGB -> DIB RGB BitBlt:       1968 ms
                         DIB RGB -> DIB RGB BitBlt:       1158 ms
                         DDB RGB -> DDB RGB BitBlt:       2267 ms
                         DIB RGB -> DDB RGB BitBlt:       2150 ms
                        DIB ARGB -> DDB RGB BitBlt:       2202 ms
              DIB ARGB -> DIB ARGB OVER AlphaBlend:       2539 ms
                      oil RGB -> RGBA oil_rgb2rgba:       2088 ms
     oil ARGB -> ARGB OVER oil_composite_over_argb:       2636 ms
                   DIB ARGB -> DIB ARGB StretchBlt:       2167 ms
                    DIB ARGB -> DIB RGB StretchBlt:       1924 ms
                     DIB RGB -> DIB RGB StretchBlt:       1136 ms
                     DDB RGB -> DDB RGB StretchBlt:       2179 ms
                DIB ARGB -> DIB ARGB StretchBlt[2]:       2152 ms
                 DIB ARGB -> DIB RGB StretchBlt[2]:       1846 ms
                  DIB RGB -> DIB RGB StretchBlt[2]:       5316 ms
                  DDB RGB -> DDB RGB StretchBlt[2]:       2091 ms
               DIB ARGB -> DIB ARGB StretchBlt[2H]:       8991 ms
                DIB ARGB -> DIB RGB StretchBlt[2H]:       7985 ms
                 DIB RGB -> DIB RGB StretchBlt[2H]:       7773 ms
                 DDB RGB -> DDB RGB StretchBlt[2H]:       9015 ms

We still need tests with "typical" *office* graphics cards!?

PS. It took me a bit to figure out how to get around the DOS window closing after the program ran. I ended up doing: gdibench.exe > c:\perf.txt

    
    

    
  

      
      
      
      

        Attached file
          
        benchmark result
        — 
      

    


  
Results from Radeon X300/X550 Series 128MB WinXP SP 2 Pentium 4

One common theme seems to be that SSE warning.  All but one has it.  Isn't it better to not use SSE if you are not sure if it is supported?  Is that done just by this tool?  Is there a command line option to tell it to not use SSE?

    
    

    
  
Windows XP supports SSE

    
    

    
  
Both of my test systems support SSE1 (Venice based Sempron 64 & Opteron Toledo), as does yours and the others I'm sure. If the tool tried to use SSE code on a non SSE CPU I'm sure it would crash, so there is no real problem there.

    
    

    
  

      
      
      
      

        Attached file
          
        Bench Results 2
        — 
      

    


  
Now from my work PC which is slow on the testcase.  
WinXP SP 2, Pentium 4, Nvidia GeForce4 MX420 64MB
Flags: blocking1.9a1? → blocking1.9+

    
    

    
  
No, the SSE warning is irrelevant; it wasn't present in Yani's post because he didn't copy it in :)

    
    

    
  
(In reply to comment #28)
> No, the SSE warning is irrelevant; it wasn't present in Yani's post because he
> didn't copy it in :)
> 
Yes,I knew it was useless.
sorry ^^


    
    

    
  
(In reply to comment #2)
> Created an attachment (id=212976) [edit]
> testcase
> 
> With the 2006-02-22 build (non-cairo) I get 4580ms for the scrolling test, cpu
> stays almost at 0%.
> With the 2006-02-23 build (cairo) I get 13940ms for the scrolling test, cpu
> gets almost 100%.

Though this test case is not a problem to me (4000-5000ms and no apparent CPU load), this URL is very slow to scroll with the background image with 2500 pixels  height.

http://www.konami.jp/kojima_pro/japanese/event/tgs_2006_event_01.html

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20061005 Minefield/3.0a1 ID:2006100520 [cairo]

    
    

    
  
http://www.gametomorrow.com/blog/

The background of this page is not exactly big (20x500) but they are tiled, and scrolling very slowly.
http://gametomorrow.com/blog/wp-content/themes/identification-band-twins-boyish/img/background.png

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20061008 Minefield/3.0a1 ID:2006100821 [cairo]

    
    

    
  
Ok, here's some analysis, finally.. thanks for all the info you guys have provided, it took me a bit to think through things to figure out what's going on.

The background here is a GIF image, and beacuse it's a background, it's being rendered with EXTEND.  GIF images used to be stored as DIBs, because they needed alpha.  However, this image in particular has no alpha, and can be represented as 24-bit, so our hyper-optimization that converts these images to DDBs kicks in.  But they're being rendered with EXTEND, so that means that we end up needing to tile in software, since win32_surface_composite doesn't support EXTEND yet.  So for every repaint we need to pull out the data from the DDB, which is kind of a performance disaster!  I have an idea how to fix this.

Whiteboard: [blocking1.9a1+]

    
    

    
  


  
This should fix this; the testcase shows significant improvement for me.
Assignee: nobody → vladimir
Status: REOPENED → ASSIGNED

        Attachment #244967 -
        Flags: review+

    
    

    
  
Checked in; resolving and crossing fingers...
Status: ASSIGNED → RESOLVED
Closed: 18 years ago → 18 years ago
Resolution: --- → FIXED

    
    

    
  
Actually that last patch had a slight hit for me.  I haven't run the test case for a while but running it on the 2006110704 nightly showed that the situation had improved for me at some point.  The test case ran in 4-5 seconds.  Now with today's nightly 2006110804 the test case runs 5-6.5 seconds.  But hey no 20's or anything like that.  

    
    

    
  
(The testcase is actually not very good for repeatable results, since it just runs at whatever your current window size is.  Should either maximize the firefox window or run the testcase with -chrome and an explicit -width -height.)

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: