Closed Bug 562038 Opened 15 years ago Closed 13 years ago

Application freezes on start with directwrite and render-mode = 6 on XP

Categories

(Core :: Graphics, defect)

x86
Windows XP
defect
Not set
critical

Tracking

()

RESOLVED INCOMPLETE

People

(Reporter: daniel, Unassigned)

References

Details

(Keywords: hang, perf)

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 Build Identifier: directwrite I enabled the D3D settings in my XULRunner application pref("gfx.font_rendering.directwrite.enabled",true); pref("mozilla.widget.render-mode",6); In most environments this works fine. However on one Windows XP notebook only the window frame will be rendered and everything inside freezes and doesn't get updated. The graphic card is: Mobile Intel 915GM/GMS,910GML Express Chipset Family Works on other XP machines and works on the named machine when I disable the D3D prefs. Reproducible: Always
Version: unspecified → Trunk
Blocks: d2d
This is probably Bug 549668, could you confirm?
Severity: normal → blocker
(In reply to comment #1) > This is probably Bug 549668, could you confirm? Hmmm... Not sure. I have this behaviour with rv:1.9.3a5pre Gecko/20100420 running on XP so this is not really related in my understanding of Bug 549668. Right?
(In reply to comment #2) > (In reply to comment #1) > > This is probably Bug 549668, could you confirm? > > Hmmm... Not sure. I have this behaviour with rv:1.9.3a5pre Gecko/20100420 > running on XP so this is not really related in my understanding of Bug 549668. > Right? Well, that's very odd, since DirectWrite code can't be touched on XP, the GPU type shouldn't be relevant. I have no idea what could be going on.
(In reply to comment #3) > Well, that's very odd, since DirectWrite code can't be touched on XP, the GPU > type shouldn't be relevant. That was my theoretical knowledge as well but in practice we just commented the two named prefs and it worked again. So XP seems to touch something. It's reproducable. How can I help in this topic? I'm really amazed of the speed improvement and the possibilities comming with DirectWrite support and would be happy to see it enabled by default.
(In reply to comment #4) > (In reply to comment #3) > > Well, that's very odd, since DirectWrite code can't be touched on XP, the GPU > > type shouldn't be relevant. > > That was my theoretical knowledge as well but in practice we just commented the > two named prefs and it worked again. So XP seems to touch something. It's > reproducable. > > How can I help in this topic? I'm really amazed of the speed improvement and > the possibilities comming with DirectWrite support and would be happy to see it > enabled by default. One thing you could do is see if enabling -only- DWrite, or -only- D2D will affect anything. Additionally, double check if this is the only XP machine you're seeing this on, and you're not seeing it on any other.
Daniel, how does this block development of firefox? https://bugzilla.mozilla.org/page.cgi?id=fields.html#status
(In reply to comment #6) > Daniel, how does this block development of firefox? > https://bugzilla.mozilla.org/page.cgi?id=fields.html#status Wayne, I don't really understand why you link to the status doc. IMHO this bug doesn't block development of firefox but it does block enabling d2d by default - see bug 549116. These prefs can cause problems on XP machines which actually should ignore these settings.
the reason I referenced the status doc is if this literally doesn't block development or testing then it is not severity=blocker. But making it block bug 549116 (would normally) adequately shows the relationship to another bug or issue, in this case in problem you cite. And if the blocking bug notation isn't enough to show how badly it is needed for a specific release, then we use blocking flags. Adding hang keyword (assuming freeze means literally that)
Severity: blocker → critical
Keywords: hang, perf
(In reply to comment #7) > (In reply to comment #6) > > Daniel, how does this block development of firefox? > > https://bugzilla.mozilla.org/page.cgi?id=fields.html#status > > Wayne, I don't really understand why you link to the status doc. > IMHO this bug doesn't block development of firefox but it does block enabling > d2d by default - see bug 549116. > These prefs can cause problems on XP machines which actually should ignore > these settings. I can't reproduce this anywhere, nor can I find anyone who can, except with older versions of FF, where this wasn't actually a bug in D2D, but a bug in the gfxWindowsPlatform pref reading code. Could you verify this is really still happening on that one machine with latest trunk?
So far I can reproduce this on only one machine. Setting pref("mozilla.widget.render-mode",6); causes the problem. Setting pref("gfx.font_rendering.directwrite.enabled",true); doesn't seem to cause any problem. Maybe we can check this at the next testday (21.05.2010) too?
(In reply to comment #10) > So far I can reproduce this on only one machine. > > Setting pref("mozilla.widget.render-mode",6); causes the problem. > > Setting pref("gfx.font_rendering.directwrite.enabled",true); doesn't seem to > cause any problem. > > Maybe we can check this at the next testday (21.05.2010) too? Must be something on that machine being messed up causing it to use an old binary or something like that. Looking at the codepath there really is -no way- on current trunk XP could be effected by that setting. The only possibility would be that somehow you ended up with a registered d3d10_1.dll, d2d1.dll and dwrite.dll on that machine. (The code simply checks if it can load all those libraries and if it can't it sets the rendermode back to GDI. This would suggest somebody put it on there and registered it manually(they wouldn't work or anything). I'm not even sure if that's possible though.
All we've done is downloading a XULRunner nightly and set the prefs. I'll try to find some more details and keep you updated (probably next week). Tests on other XP machines worked well.
(In reply to comment #12) > All we've done is downloading a XULRunner nightly and set the prefs. I'll try > to find some more details and keep you updated (probably next week). > > Tests on other XP machines worked well. Try making sure all your profiles are purged and no other firefox binaries are running. Make sure you run the nightly with -no-remote so that it's not remoting to using another binary :s. That's the only other thing I can think of.
Daniel, can you update the bug with you current status please? thanks
Wayne, I don't have access to the machine anymore. I would mark the bug as resolved (WFM).
Status: UNCONFIRMED → RESOLVED
Closed: 13 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.