Closed Bug 595614 Opened 14 years ago Closed 14 years ago

[D2D] Resizing window is sluggish and laggy

Categories

(Core :: Graphics, defect)

x86
Windows Vista
defect
Not set
normal

Tracking

()

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

People

(Reporter: wddn836, Unassigned)

References

Details

(Keywords: perf, regression)

Attachments

(3 files)

User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:2.0b5) Gecko/20100101 Firefox/4.0b5 Build Identifier: Mozilla/5.0 (Windows NT 6.0; rv:2.0b5) Gecko/20100101 Firefox/4.0b5 Resizing window is sluggish and laggy w/ D2D turned on. Greyish area is often found when resizing. Reproducible: Always Steps to Reproduce: 1.Open Firefox 4 Beta 5 w/ hardware accleration turned on 2.resize Firefox window Actual Results: Sluggish, laggy and slow Expected Results: Smooth resizing Graphics: GeForce 9600GT CPU: Intel Core 2 Duo E6400@2.13Ghz
Does this issue happen with a new profile : http://support.mozilla.com/en-US/kb/managing+profiles Please, can you provide as an attachment: * a screenshot of the greyish area * a text file that contains "about:support" page
Component: General → Graphics
Product: Firefox → Core
QA Contact: general → thebes
Attached file About:support (deleted) —
Attached video Resizing speed compared to Chrome (deleted) —
Resizing is apparently much smoother in Chrome. I chose Chrome over Firefox w/o hw acceleration because it's not possible for me to open two Firefox windows with one accelerated and the other not.
Attached video "Greyish Area" (deleted) —
I can't capture a screenshot, so I made a video instead. And yes this does happen with a new profile.
Thank you for your attachments. If you want to use FF 4.0b5, you can untick "Options > Advanced > Use HW acceleration when available" and then restart FF.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Version: unspecified → Trunk
This is a known problem that will be resolved soon.
Bas: is there a bug that will be fixing this? Or a meta off of which we should hang this?
It should be largely fixed by D3D9 layers. It could be fixed for D2D specifically as well. But since pretty much everyone who gets D2D will also get D3D9 layers I never spent much time on it. On the latest trunk builds with D3D9 on by default this is looking pretty good for me.
I should note that although it's a lot better on D3D9 trunk, this is still a little slower than GDI. Partially there's nothing we can do about it because resizing hardware accelerated windows is slightly more expensive than resizing normal windows. However that does not mean there's no room for improvement. I think performance with D3D9 is good enough for Beta 6 though.
Blocks: slowui
(In reply to comment #4) > Created attachment 474525 [details] > "Greyish Area" This is also now White using Win 7 instead of gray per bug 574638.
blocking2.0: --- → ?
This is much better when using D3D9 layers, and will improve further with D3D10 layers. If it is still a significant problem on nightlies on some machines please re-open. Note that it will always be a bit slower than GDI there's nothing we can do about that.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
I have this problem long time ago. Resizing is the windows is slow. Slower than Fx3.x. The performance is regardless to D2D/layers. It's the same with and without them. And that bug with the white area, wich you can see on the video, very annoying. (it was greyish, it's now white) I think this bug should be reopened. Anyway, i'm on Win7, with a 8800GT.
I am still getting laggy resizing in the latest JS build. I know it will always be slower than GDI but it seems that IE9 is doing a pretty good job. I get very smooth resizing in IE9 esp. when compared with Fx4. There's definitely still a lot of room for improvement. Anyone think I should reopen this bug?
(In reply to comment #14) > I am still getting laggy resizing in the latest JS build. I know it will > always be slower than GDI but it seems that IE9 is doing a pretty good job. I > get very smooth resizing in IE9 esp. when compared with Fx4. There's > definitely still a lot of room for improvement. > > Anyone think I should reopen this bug? IE9 is 'kind of' cheating. Their chrome area is actually plain old GDI, and only their content area is a hardware accelerated child window I believe. Their resizing feels a lot smoother because of this, but if you look at the edges of their content area you can see that the content area resizes almost as sluggish as ours (still a wee bit better than us though).
(In reply to comment #13) > I have this problem long time ago. > > Resizing is the windows is slow. Slower than Fx3.x. > The performance is regardless to D2D/layers. It's the same with and without > them. > > And that bug with the white area, wich you can see on the video, very annoying. > (it was greyish, it's now white) > > I think this bug should be reopened. > > Anyway, i'm on Win7, with a 8800GT. If resizing the window is slower without D2D -and- D3D9. Please open a separate bug, this would be unexpected and something's wrong. I'd like to keep this bug open for possible slowdowns related to D2D or D3D9. If either is turned on it will be a bit slower. It will be significantly slower if D2D is turned on but D3D9 is not.
I shall see if the problem would be any better when beta 7 is released. I won't expect it to be as smooth as GDI, but I hope the lag would at least be less noticeable.
>Their chrome area is actually plain old GDI Pff, interesting approach... >I'd like to keep this bug open for possible slowdowns related to D2D or D3D9. Please do not consider my previous post. I was stupid, and tested on my everyday profile. It seems my extensions screwed this up. Anyway, i tested now on fresh profile: W/o any HW ACC: it's very smooth W/ layers only: same very smooth w/ D2D only: very sluggish W/ D2D+layers: sluggish, but not that bad w/o layers
Actually what's the point of accelerating the chrome area if there's no performance benefit at all? If it only makes matters worst, why not follow IE's approach?
blocking2.0: ? → betaN+
Keywords: perf, regression
Resolution: FIXED → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: