Firefox Panorama zoom-in is slow on some web pages, such as twitter.com (after being logged in)

RESOLVED WONTFIX

Status

()

Core
Graphics
P2
normal
RESOLVED WONTFIX
7 years ago
4 years ago

People

(Reporter: ted, Unassigned)

Tracking

({perf})

Trunk
Future
x86
Windows XP
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(blocking2.0 -)

Details

(Reporter)

Description

7 years ago
When I click on a tab in the Panorama view, and the zoom-in transition animates, it's terribly slow. It looks like I get 2 or 3 animation frames at most. On my Linux and Mac machines it's much smoother.

I'm on a Core 2 Duo, 4GB ram. My graphics card is a Radeon X1300/X1550 Series, with the WDDM drivers. I'm running Windows 7 x64. I don't have D2D enabled (my card is only a DX9 card, I've been told), but I do have DWrite enabled.
How about if you enable D3D9? Try MOZ_ACCELERATED=1
(Reporter)

Comment 2

7 years ago
Seems slightly better, although still not as fast as on Linux (where I'm using Intel onboard video), or on Mac (where it's smooth like butter).

Updated

7 years ago
blocking2.0: --- → ?
Ted, what's in your graphics section of about:support?
(Reporter)

Comment 4

7 years ago
        Adapter Description
        Radeon X1300/X1550 Series (Microsoft Corporation - WDDM)

        Vendor ID
        1002

        Device ID
        7183

        Adapter RAM
        Unknown

        Adapter Drivers
        atiumdag atiumdva atiumd64 atiumd6a atitmm64

        Driver Version
        8.56.1.15

        Driver Date
        4-24-2009

        Direct2D Enabled
        false

        DirectWrite Enabled
        true

      GPU Accelerated Windows
      1/1 Direct3D 9
We need D3D9 at least to be fast at this.
Assignee: nobody → jmuizelaar
Group: mozilla-corporation-confidential
blocking2.0: ? → final+
(Reporter)

Comment 6

7 years ago
Did you intentionally flip the moco confidential flag here? (I'm guessing not...)
nope! crap.
Group: mozilla-corporation-confidential

Comment 8

7 years ago
So, I could easily reproduce this in Mac and Windows.  Both show kind of the same behavior on heavy-weight web pages.  One good web page to reproduce this on is twitter.com.

Aza, Ian, I think we should sit down next week and discuss how we can make stuff better here.  I have a few ideas about starting the reflow (and/or paint) process earlier than when we actually start the zooming operation, because the bottleneck here seems to be the amount of time we spend on painting the full size page again when the animation is finished.  Can we do that next week?
Summary: Firefox Panorama zoom-in is slow on Windows → Firefox Panorama zoom-in is slow on some web pages, such as twitter.com (after being logged in)
Assignee: jmuizelaar → ehsan
Interesting... we actually have been repainting the thumbnails speculatively (before any zoom is requested) so we don't have to do a repaint once we know we need to zoom. That's actually going to change, however, with bug 609685. 

Also note that we're thinking about using WebGL for the zoom (bug 617463). 

At any rate, if you've got ideas for speeding up our zoom animation, I'm all for it!
Blocks: 598154
Keywords: perf

Comment 10

7 years ago
(In reply to comment #9)
> Interesting... we actually have been repainting the thumbnails speculatively
> (before any zoom is requested) so we don't have to do a repaint once we know we
> need to zoom.

Hmm, that might have lead to painting too soon.  Has that actually improved performance?  Which bug did make that change?

> That's actually going to change, however, with bug 609685. 

How is this going to change?  Any change here should be evaluated to make sure that it doesn't regress performance.

> Also note that we're thinking about using WebGL for the zoom (bug 617463). 

I talked that out with the gfx guys, that's not gonna help at all, and at this point I don't think it's something that we want to do.

> At any rate, if you've got ideas for speeding up our zoom animation, I'm all
> for it!

Well, we should first talk about how things work, to enable me understand everything I need to know without reading the entire code.  Once I have that understanding, I will come up with a set of concrete suggestions which we can try and measure the performance benefit of each one.
(In reply to comment #10)
> (In reply to comment #9)
> > Interesting... we actually have been repainting the thumbnails speculatively
> > (before any zoom is requested) so we don't have to do a repaint once we know we
> > need to zoom.
> 
> Hmm, that might have lead to painting too soon.  Has that actually improved
> performance?  Which bug did make that change?

That's the way it's been since the beginning. 
 
> > That's actually going to change, however, with bug 609685. 
> 
> How is this going to change?  Any change here should be evaluated to make sure
> that it doesn't regress performance.

With that patch we'll be doing a canvas drawWindow call (with no layout flush) right at the beginning of the zoom. Sean says this doesn't seem to make the zoom any chunkier, but we don't really have a good objective way to test "chunkiness".

> Well, we should first talk about how things work, to enable me understand
> everything I need to know without reading the entire code.  Once I have that
> understanding, I will come up with a set of concrete suggestions which we can
> try and measure the performance benefit of each one.

Sounds good; find me on IRC and we can chat or phone call.

Thanks!
blocking2.0: final+ → -

Comment 12

7 years ago
(In reply to comment #11)
> > > That's actually going to change, however, with bug 609685. 
> > 
> > How is this going to change?  Any change here should be evaluated to make sure
> > that it doesn't regress performance.
> 
> With that patch we'll be doing a canvas drawWindow call (with no layout flush)
> right at the beginning of the zoom. Sean says this doesn't seem to make the
> zoom any chunkier, but we don't really have a good objective way to test
> "chunkiness".

So, this was minused because it's just a small level of slowness, and not a huge performance hit.  If one of the people on the Panorama team can find a web page on which this problem is much worse to the point of making the browser unusable, they should post the URL and renominate for blocking.  Otherwise, I probably won't have enough time to look into this for Firefox 4, as I'm currently focused on blockers.

Updated

7 years ago
Blocks: 604213
OS: Windows 7 → Windows XP
Priority: -- → P2
Target Milestone: --- → mozilla2.0b8

Comment 13

7 years ago
bugspam (moving b9 to b10)
Blocks: 608028

Comment 14

7 years ago
bugspam (removing b9)
No longer blocks: 598154

Updated

7 years ago
Depends on: 624505
This feels like a amorphous bug description, imho... but adding to our beta 11 tracking bug for profiling work, in case someone wants to take it up.

(In reply to comment #12)
> Otherwise, I
> probably won't have enough time to look into this for Firefox 4, as I'm
> currently focused on blockers.

Unassigning you, then.

Adding the rest of the Panorama Perf All-Star Team.
Assignee: ehsan → nobody
Blocks: 627096
No longer blocks: 608028
Target Milestone: mozilla2.0b8 → ---
Too late for this for Fx4
No longer blocks: 627096
Target Milestone: --- → Future
We're not going to address this with Panorama being slated for removal.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.