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

Status: RESOLVED INCOMPLETE

(Core :: Graphics, defect)

Description

[Daniel Kirsch]

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

Comment 1

[Bas Schouten (:bas.schouten)]

This is probably Bug 549668, could you confirm?

Comment 2

[Daniel Kirsch]

(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?

Comment 3

[Bas Schouten (:bas.schouten)]

(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.

Comment 4

[Daniel Kirsch]

(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.

Comment 5

[Bas Schouten (:bas.schouten)]

(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.

Comment 6

[Wayne Mery (:wsmwk)]

Daniel, how does this block development of firefox? https://bugzilla.mozilla.org/page.cgi?id=fields.html#status

Comment 7

[Daniel Kirsch]

(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.

Comment 8

[Wayne Mery (:wsmwk)]

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)

Comment 9

[Bas Schouten (:bas.schouten)]

(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?

Comment 10

[Daniel Kirsch]

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?

Comment 11

[Bas Schouten (:bas.schouten)]

(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.

Comment 12

[Daniel Kirsch]

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.

Comment 13

[Bas Schouten (:bas.schouten)]

(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.

Comment 14

[Wayne Mery (:wsmwk)]

Daniel, can you update the bug with you current status please?  thanks

Comment 15

[Daniel Kirsch]

Wayne,
I don't have access to the machine anymore. I would mark the bug as resolved (WFM).