Closed
Bug 328380
Opened 19 years ago
Closed 18 years ago
Bad scrolling performance with Cairo builds using large fixed positioned background-image
Categories
(Core :: Graphics, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: martijn.martijn, Assigned: vlad)
References
Details
(Keywords: perf, testcase, Whiteboard: [blocking1.9a1+])
Attachments
(5 files)
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.
Reporter | ||
Comment 1•19 years ago
|
||
Reporter | ||
Comment 2•19 years ago
|
||
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%.
Reporter | ||
Updated•19 years ago
|
Flags: blocking1.9a1?
Comment 3•19 years ago
|
||
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...
Reporter | ||
Comment 4•19 years ago
|
||
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.
Updated•19 years ago
|
Updated•19 years ago
|
Comment 5•18 years ago
|
||
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
Reporter | ||
Comment 6•18 years ago
|
||
Peter, see bug 328367
Comment 7•18 years ago
|
||
Yep, just found it too (and had a mid-air collision with your comment) :-)
Assignee | ||
Comment 8•18 years ago
|
||
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.)
Assignee | ||
Comment 9•18 years ago
|
||
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.
Assignee | ||
Comment 10•18 years ago
|
||
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?
Reporter | ||
Comment 11•18 years ago
|
||
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?
Assignee | ||
Comment 12•18 years ago
|
||
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
Comment 13•18 years ago
|
||
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).
Comment 14•18 years ago
|
||
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.
Comment 15•18 years ago
|
||
(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.
Reporter | ||
Comment 16•18 years ago
|
||
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 → ---
Comment 17•18 years ago
|
||
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.
Comment 18•18 years ago
|
||
(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. ^^
Comment 19•18 years ago
|
||
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
Assignee | ||
Comment 20•18 years ago
|
||
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?
Comment 21•18 years ago
|
||
(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
Comment 22•18 years ago
|
||
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
Comment 23•18 years ago
|
||
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
Comment 24•18 years ago
|
||
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?
Comment 25•18 years ago
|
||
Windows XP supports SSE
Comment 26•18 years ago
|
||
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.
Comment 27•18 years ago
|
||
Now from my work PC which is slow on the testcase.
WinXP SP 2, Pentium 4, Nvidia GeForce4 MX420 64MB
Assignee | ||
Updated•18 years ago
|
Flags: blocking1.9a1? → blocking1.9+
Assignee | ||
Comment 28•18 years ago
|
||
No, the SSE warning is irrelevant; it wasn't present in Yani's post because he didn't copy it in :)
Comment 29•18 years ago
|
||
(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 ^^
Comment 30•18 years ago
|
||
(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]
Comment 31•18 years ago
|
||
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]
Assignee | ||
Comment 32•18 years ago
|
||
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.
Assignee | ||
Updated•18 years ago
|
Whiteboard: [blocking1.9a1+]
Assignee | ||
Comment 33•18 years ago
|
||
This should fix this; the testcase shows significant improvement for me.
Assignee | ||
Comment 34•18 years ago
|
||
Checked in; resolving and crossing fingers...
Status: ASSIGNED → RESOLVED
Closed: 18 years ago → 18 years ago
Resolution: --- → FIXED
Comment 35•18 years ago
|
||
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.
Assignee | ||
Comment 36•18 years ago
|
||
(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.
Description
•