Closed Bug 626227 Opened 9 years ago Closed 9 years ago

Opening panorama causes unresponsive GUI

Categories

(Core :: Graphics, defect)

x86
Windows 7
defect
Not set

Tracking

()

RESOLVED FIXED
Tracking Status
blocking2.0 --- betaN+

People

(Reporter: scott001, Assigned: bas.schouten)

Details

(Whiteboard: [hardblocker])

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b10pre) Gecko/20110116 Firefox/4.0b10pre
Build Identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b10pre) Gecko/20110116 Firefox/4.0b10pre

GUI becomes unresponsive for rest of session after panorama has been opened.

Reproducible: Always

Steps to Reproduce:
1. Load a few tabs (example: Youtube, Ebay, Yahoo)
2. Open panorama, then close panorama
3. Try switching between tabs, using other GUI features and browsing through the pages.
Actual Results:  
GUI becomes sluggish and unresponsive, particularly tab switching and scrolling, for the rest of the session.

Expected Results:  
Browser should remain responsive.

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b10pre) Gecko/20110116 Firefox/4.0b10pre

1/1 Direct3D 10

D2D/DirectWrite: true (6.1.7600.20830)

Latest Nvidia driver.
Keywords: regression
blocking2.0: --- → ?
Severity: major → normal
> 3. Try switching between tabs, using other GUI features and browsing through
> the pages.

Scott, can you tell walk us through exactly what kinds of actions these are? How did you switch between tabs? What other GUI features?
(In reply to comment #1)
> > 3. Try switching between tabs, using other GUI features and browsing through
> > the pages.
> 
> Scott, can you tell walk us through exactly what kinds of actions these are?
> How did you switch between tabs? What other GUI features?
Switching between tabs using mouse click.. Other GUI features such as scrolling through bookmarks and history panel.
Found the regression window:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=9c32afba1189&tochange=aa14a8d4c97b

Confirmed it twice between those builds... Also disabling HWA fixes it too, so it is caused by Bug 622482
It's more likely to be a layers problem than a problem specifically with that patch.
the gui on my system is unresponsive even without using panorama, scrolling my bookmark sidebar is like 10x slower with very high cpu usage with today nightly compared to yesterday's one.

8800GT D2D/Direct3D 10
(In reply to comment #5)
> the gui on my system is unresponsive even without using panorama, scrolling my
> bookmark sidebar is like 10x slower with very high cpu usage with today nightly
> compared to yesterday's one.
> 
> 8800GT D2D/Direct3D 10

With the tab switching delays I don't see it until I open panorama atleast once during the session. Then tab switching goes from instantaneous to 1-2+ second delay. It also has an impact on any further browsing actions, browser needs restarted to perform correctly again.

Works fine: 20110115123545 9c32afba1189
Broken:     20110115183417 aa14a8d4c97b
Hrm, I cannot reproduce this issue but it's probably indeed related to the manual glyph rendering code. We need to figure out what's going on here, if we can't, another option is to try and use a STAGING resource there and update a hardware texture from there rather than a DYNAMIC resource. Although that's a long shot it's the only thing I can think of right now.
It may be something system specific or may not be as pronounced on a faster desktop machine, from what I see the CPU load is not unusual, doesn't seem to be I/O, it might be GPU/Graphic load, would have to get a program to see GPU%. System: ASUS laptop, 2.4ghz core2duo, Nvidia g102m 512mb (with beta driver), 4GB ram, disk drive.
I'm seeing this on a fairly speedy i7/6gb/460gtx system, not very pronounced, but once it was pointed out, I could reproduce.

Could Bug 626240 be the cause?
(In reply to comment #0)

> 
> GUI becomes unresponsive for rest of session after panorama has been opened.
> 

I think that the main part of performance regression in UI responsiveness, come from correlated bug:  


Bug 606148 When Panorama starts to stack tabs, it becomes extremely slow:

https://bugzilla.mozilla.org/show_bug.cgi?id=606148
On opening panorama, my memory usage seems to briefly spike to 1GB+, with just two tabs open! Investigating this now.
So, I think I know what's happening here, although I have not yet gathered sufficient evidence to prove it, but I'm going to try a fix.

The problem begins with Panorama using canvases with an alpha channel. When we then proceed to execute DrawWindow to these canvasese we'll get a lot of drawing using the codepath added in bug 622482. This codepath will then execute a lot of calls using the dynamic temporary text rendering texture. Each time we update this we map the whole thing assuming we'll be writing to the VRAM directly, this is not true when we have more of these calls in the GPU pipeline, simply because each of the calls will need different data in that location in VRAM, and the execution does not run synchronously.

In the NVidia situation (and perhaps others) this is not actually the case. For -each- drawglyph call the driver will allocate 4 MB of DMA-able memory so that the pipeline can DMA this when it's required. This is an undesirable situation since it leads to spiking memory usage and a significant amount of page thrashing.

I'm looking for a solution in using a slightly different method, which in the one-call-per-frame case will be slightly slower but in general should result in much improved performance. I'm going to use the UpdateSubResource API: http://msdn.microsoft.com/en-us/library/bb173621%28v=vs.85%29.aspx
This isn't a regression since Panorama doesn't exist in 3.6.
Assignee: nobody → bas.schouten
Status: UNCONFIRMED → NEW
blocking2.0: ? → betaN+
Component: TabCandy → Graphics
Ever confirmed: true
Keywords: regression
Product: Firefox → Core
QA Contact: tabcandy → thebes
Whiteboard: [hardblocker]
I've changed my mind and decided I will create STAGING textures for each text run the size of the bounds of the textrun, to avoid 1 of the potential copies during a resource contention situation.
This patch makes us use staging intermediate textures for the textruns, this fixes the issues for me. Fired this at try to test performance.
Attachment #504326 - Flags: review?(jmuizelaar)
That was fast, I can test out the try build when available.
(In reply to comment #12)
> The problem begins with Panorama using canvases with an alpha channel. When we
> then proceed to execute DrawWindow to these canvasese we'll get a lot of
> drawing using the codepath added in bug 622482.

Why?

Either they're drawing with USE_WIDGET_LAYERS, in which case we only draw text to the normal retained layer tree so there's no more drawing text to RGBA surfaces than usual, or they're not drawing with USE_WIDGET_LAYERS in which case the destination surface should have subpixel antialiasing disabled.
Also, in bug 624101 Panorama's canvases will be marked moz-opaque. I presume that will help here.
Comment on attachment 504326 [details] [diff] [review]
Use staging resource for our textruns

># HG changeset patch
># Parent 6c727b25207a8c8723cf21e9f72363225011a26e
>try: -b o -p win32 -u all -t all 
>
>diff --git a/gfx/cairo/cairo/src/cairo-d2d-surface.cpp b/gfx/cairo/cairo/src/cairo-d2d-surface.cpp
>--- a/gfx/cairo/cairo/src/cairo-d2d-surface.cpp
>+++ b/gfx/cairo/cairo/src/cairo-d2d-surface.cpp
>@@ -247,18 +247,17 @@ cairo_d2d_create_device_from_d3d10device
>     if (FAILED(hr)) {
> 	goto FAILED;
>     }
>     device->base.refcount = 1;
> 
>     // We start out with TEXT_TEXTURE roughly in VRAM usage.
>     device->mVRAMUsage = TEXT_TEXTURE_WIDTH * TEXT_TEXTURE_HEIGHT * 4;
> 
>-    textDesc.Usage = D3D10_USAGE_DYNAMIC;
>-    textDesc.CPUAccessFlags = D3D10_CPU_ACCESS_WRITE;
>+    textDesc.Usage = D3D10_USAGE_DEFAULT;

Please add a comment when specifying the usage about why it needs to be a particular usage.

>     hr = device->mD3D10Device->CreateTexture2D(&textDesc, NULL, &device->mTextTexture);
>     if (FAILED(hr)) {
> 	goto FAILED;
>     }
> 
>     hr = device->mD3D10Device->CreateShaderResourceView(device->mTextTexture,
> 							NULL,
> 							&device->mTextTextureView);
>@@ -3599,18 +3598,28 @@ _cairo_dwrite_manual_show_glyphs_on_d2d_
>     ID3D10Device1 *device = dst->device->mD3D10Device;
> 
>     int textureWidth, textureHeight;
> 
>     if (cairo_bounds.width < TEXT_TEXTURE_WIDTH &&
> 	cairo_bounds.height < TEXT_TEXTURE_HEIGHT)
>     {
> 	// Use our cached TextTexture when it is big enough.
>+	RefPtr<ID3D10Texture2D> tmpTexture;
>+	CD3D10_TEXTURE2D_DESC desc(DXGI_FORMAT_B8G8R8A8_UNORM,
>+				   cairo_bounds.width, cairo_bounds.height,
>+				   1, 1, 0);
>+
>+	desc.Usage = D3D10_USAGE_STAGING;
>+	desc.CPUAccessFlags = D3D10_CPU_ACCESS_WRITE;
>+				   
>+	hr = device->CreateTexture2D(&desc, NULL, &tmpTexture);
>+
> 	D3D10_MAPPED_TEXTURE2D texMap;
>-	hr = dst->device->mTextTexture->Map(0, D3D10_MAP_WRITE_DISCARD, 0, &texMap);
>+	hr = tmpTexture->Map(0, D3D10_MAP_WRITE, 0, &texMap);
> 

[snip]

> 
>-	dst->device->mTextTexture->Unmap(0);
>+	tmpTexture->Unmap(0);
> 
> 	delete [] texture;
> 
>+	D3D10_BOX box;
>+	box.front = box.left = box.top = 0;
>+	box.back = 1;
>+	box.right = cairo_bounds.width;
>+	box.bottom = cairo_bounds.height;
>+
>+	device->CopySubresourceRegion(dst->device->mTextTexture, 0, 0, 0, 0, tmpTexture, 0, &box);

I'd do:
// Copy over the tmp texture to the text texture
D310_BOX box = D3D10_BOX_from_cairo_rect(cairo_bounds);
device->CopySubresouceRegion(dst->device->mTextTexture, 0, 0, 0, 0, tmpTexture, 0, &box);
Attachment #504326 - Flags: review?(jmuizelaar) → review+
http://hg.mozilla.org/mozilla-central/rev/ea0d32edf11b
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.