User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b9pre) Gecko/20101218 Firefox/4.0b9pre Build Identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b9pre) Gecko/20101218 Firefox/4.0b9pre Hello compared to other browsers the blowing is slow. - Internet Explorer 9 pre 7 - Opera 11 (1156) - Google Chrome 10.0.614.0 canary build Please try to speed it up. Thanks Reproducible: Always Steps to Reproduce: 1. open the url 2. click (repeatedly) on the video

Reporter, please can you confirm whether this issue still occurs using Firefox 4.0.1 (http://www.mozilla.com/firefox/new/) or higher, in Firefox safe mode (http://support.mozilla.com/kb/Safe+Mode) and/or with a clean profile (http://support.mozilla.com/kb/Basic+Troubleshooting#w_8-make-a-new-profile). Ideally, also check using the latest nightly: http://nightly.mozilla.org/ If this issue no longer occurs, please close as "Resolved Worksforme". It it in fact still occurs, please provide as much extra information as possible, including what versions tried, whether safe mode/new profile tested etc. Thanks! :-) (Template reply to inactive UNCO bugs)

Hello Ed Morley I have tested it now with the Nightly again: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0a1) Gecko/20110503 Firefox/6.0a1 In safe mode it is fast. With a clean profile it is slow. It seams to have something to do with the Direct2D acceleration. If I set: gfx.direct2d.disabled;true = fast gfx.direct2d.disabled;false = slow If you like I can create videos next weekend. I will now attach the new about:support and DxDiag files.

Thanks for the extra info. Can you try updating your graphics card driver and seeing it that helps please: http://www.nvidia.com/Download/index.aspx

It is still the same with v275.27 beta drivers and Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0a1) Gecko/20110517 Firefox/6.0a1 Do you need videos of it?

Confirmed with build: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0a1) Gecko/20110517 Firefox/6.0a1 D2D enabled: slow. D2D disabled: fast. CC'ing Bas.

Odd, this seems to perform just fine for me :s

Hrm, on another machine with an NVidia card I can reproduce this, I'll have a more detailed look soon.

Confirmed on http://hg.mozilla.org/mozilla-central/rev/f717485edc51 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0a1) Gecko/20110517 Firefox/6.0a1 ID:20110517030625 Graphics Adapter Description: ATI Radeon HD 4300/4500 Series Vendor ID: 1002 Device ID: 954f Adapter RAM: 512 Adapter Drivers: aticfx64 aticfx64 aticfx32 aticfx32 atiumd64 atidxx64 atiumdag atidxx32 atiumdva atiumd6a atitmm64 Driver Version: 8.850.0.0 Driver Date: 4-19-2011 Direct2D Enabled: true DirectWrite Enabled: true (6.1.7601.17563) ClearType Parameters: Gamma: 2200 Pixel Structure: RGB ClearType Level: 50 Enhanced Contrast: 50 WebGL Renderer: Google Inc. -- ANGLE -- OpenGL ES 2.0 (ANGLE 0.0.0.611) GPU Accelerated Windows: 1/1 Direct3D 10 Regression window(m-c): Works: http://hg.mozilla.org/mozilla-central/rev/656d99ca089c Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b4pre) Gecko/20100814 Minefield/4.0b4pre ID:20100814040443 Fails: http://hg.mozilla.org/mozilla-central/rev/bffe7baa4e00 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b4pre) Gecko/20100813 Minefield/4.0b4pre ID:20100816004710 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=656d99ca089c&tochange=bffe7baa4e00 Note: Between the above range it is hard-coded to dusable D2D, so I cannot bisect without local build.

s/dusable/disable/

I reproduced on this hardware: Adapter: NVIDIA GeForce 8800 GT Vendor ID: 10de Device ID: 0611 Adapter RAM: 512 Adapter drivers: nvd3dumx,nvwgf2umx,nvwgf2umx nvd3dum,nvwgf2um,nvwgf2um Driver version: 8.17.12.7061 Driver date: 4-7-2011 Direct2D enabled: true DirectWrite enabled: true (6.1.7601.17563) ClearType Parameters: ClearType parameters not found WebGL Renderer: NVIDIA Corporation -- GeForce 8800 GT/PCI/SSE2 -- 3.3.0 GPU Accelerated Windows: 1/1 Direct3D 10

Runs fine on: Adapter Description AMD Radeon HD 6900 Series Vendor ID 1002 Device ID 6718 Adapter RAM 2048 Adapter Driver saticfx64 aticfx64 aticfx64 aticfx32 aticfx32 aticfx32 atiumd64 atidxx64 atidxx64 atiumdag atidxx32 atidxx32 atiumdva atiumd6a atitmm64 Driver Version 8.850.6.0 Driver Date 5-5-2011 Direct2D Enabledtrue DirectWrite Enabled true (6.1.7601.17563) ClearType Parameters DISPLAY1 [ Gamma: 2200 Pixel Structure: RGB ClearType Level: 100 Enhanced Contrast: 100 ] DISPLAY4 [ Gamma: 2200 Pixel Structure: RGB ClearType Level: 100 Enhanced Contrast: 100 ] WebGL Renderer: Google Inc. -- ANGLE -- OpenGL ES 2.0 (ANGLE 0.0.0.611) GPU Accelerated Windows1/1 Direct3D 10

gfx.direct2d.disabled;true = fast, but look at the edges of those rectangles. Every piece is rendered totally aliased. gfx.direct2d.disabled;false = slow(er a bit on my build), but all the little pieces are nicely anti-aliased. This could reasonably eat up processing a lot more processing power, thus the slowdown.

In local build(Force enabled D2D): build from 0fb6352dc09c + f2959b949445 : fails build from 07822d2a6758 + f2959b949445 :works So, Triggered by: Bug 587316 - [d2d] Fix mochitest canvas mochitest failures

(In reply to comment #15) > In local build(Force enabled D2D): > build from 0fb6352dc09c + f2959b949445 : fails > build from 07822d2a6758 + f2959b949445 :works > So, Triggered by: > Bug 587316 - [d2d] Fix mochitest canvas mochitest failures Hrm that's interesting, and a little surprising, I wonder what part of that patch did it.

I suspect this is because of DrawImage using EXTEND_NONE, shouldn't be hard to fix.

(In reply to comment #17) > I suspect this is because of DrawImage using EXTEND_NONE, shouldn't be hard > to fix. Yes, build from 055a407bb683 + f2959b949445 : fails build from 1d7c15818f66 + f2959b949445 :works Triggered by: 055a407bb683 Bas Schouten — Bug 587316 - Part 4: Support CAIRO_EXTEND_NONE for D2D source surfaces. r=jrmuizel

This patch fixes the bug. In general EXTEND_PAD should generate better results than EXTEND_NONE for DrawImage.

Comment on attachment 533095 [details] [diff] [review] Use EXTEND_PAD when doing DrawImage rather than EXTEND_NONE Review of attachment 533095 [details] [diff] [review]: -----------------------------------------------------------------

This caused a reftest failure on linux, need to figure out why and fix.

Due to no longer sampling transparent pixels wrongfully, three reftests are no longer failing on none-MacOSX (where EXTEND_NONE doesn't behave according to the cairo specification). This marks them passing everywhere now.

Comment on attachment 533136 [details] [diff] [review] Part 2: Mark several reftests passing now Review of attachment 533136 [details] [diff] [review]: ----------------------------------------------------------------- Nice!

http://hg.mozilla.org/mozilla-central/rev/4b8d96e463fd http://hg.mozilla.org/mozilla-central/rev/1da1a471627d

scoobidiver, has this spiked up in crash reports? Why did you nominate it as a concern for Firefox 5?

(In reply to comment #26) > has this spiked up in crash reports? It is not a crash but a perf issue discovered in Firefox 4. > Why did you nominate it as a concern for Firefox 5? According to me, a single patch that is validated must be transfered to Firefox 5. By single patch, I mean a fix and not something that is caused by a new feature. Only a verified status is needed in order to do the transfer.

(In reply to comment #27) > (In reply to comment #26) > > has this spiked up in crash reports? > It is not a crash but a perf issue discovered in Firefox 4. > > > Why did you nominate it as a concern for Firefox 5? > According to me, a single patch that is validated must be transfered to > Firefox 5. By single patch, I mean a fix and not something that is caused by > a new feature. Only a verified status is needed in order to do the transfer. Although I'd gladly see this in Firefox 5. Since this is not a regression in 4 I doubt it is eligible to be merged onto Firefox 5 if I understand our criteria correctly.

(In reply to comment #28) > Although I'd gladly see this in Firefox 5. Since this is not a regression in > 4 I doubt it is eligible to be merged onto Firefox 5 if I understand our > criteria correctly. You don't. I meant, a bug in Firefox 4 that has been fixed and verified in mozilla-central must be transfered to Firefox 5, except if the bug fix is a new Firefox 6 feature.

The criteria for getting into Firefox 5 at this late stage is stringent. It must be very high value and well understood. We must also have solid confidence that it doesn't break anything. I don't think that this change qualifies.

Ask an for an approval on the patch.