Closed Bug 618868 Opened 14 years ago Closed 14 years ago

Consider whether to keep hardware acceleration on in Thunderbird 3.3

Categories

(Thunderbird :: General, defect)

defect
Not set
normal

Tracking

(blocking-thunderbird5.0 needed)

RESOLVED WORKSFORME
Tracking Status
blocking-thunderbird5.0 --- needed

People

(Reporter: rain1, Assigned: Bienvenu)

References

Details

We currently have hardware acceleration (both content and compositing) [1] on in trunk builds. We need to decide whether to keep it on or turn it either partially or fully off for our first trunk release. Arguments for keeping it on: * It's what Firefox does. * There might be a perf improvement with scrolling thread lists and such. Arguments for turning Direct2D/DirectWrite (content acceleration on Windows) off: * The font rendering is a little iffy in some circumstances, e.g. bug 594325. Seems like this will require a fix from Microsoft, pushed over Windows Update. * There's a tremendous hit to cold startup times right now: bug 600713. * Even after everything is fixed, I understand there will be a non-zero hit to startup times because the renderer has to be initialized, etc. Arguments for turning compositing acceleration off: * Again, I understand there will be a non-zero hit to startup times. All the performance claims above are anecdotal, so we need measurements here. Disabling hardware acceleration is easy. content on Windows: set gfx.direct2d.disabled to true compositing: set layers.accelerate-none to true [1] https://hacks.mozilla.org/2010/09/hardware-acceleration/
blocking-thunderbird5.0: --- → ?
Setting blocking to needed as I feel that we need some concious decision on this before the next trunk release, but we're not in a position to make that yet.
blocking-thunderbird5.0: ? → needed
See Also: → 594325, 600713
I suspect the fix in bug 602792 means we can leave it on. Cc'ing John to make sure I haven't misread the comments in bug 602972 and bug 600713.
Other than the issue with compositing (not really aware of what this is), this isn't really "render with hardware acceleration" or without, it's "use DirectWrite font APIs" vs. "use GDI font APIs". Since DirectWrite isn't available on XP, Gecko is required to support both. Hardware acceleration requires the use of DirectWrite, that's why all these issues appear to be tied to hardware acceleration. I think most of the issues with cold startup time (actually bug 602792, not bug 600713) were worked around somewhat for FF4 and Microsoft fixed the underlying OS issue in March: http://support.microsoft.com/kb/2505438 Although this bug was nasty, DirectWrite and its related components is the main font subsystem for Microsoft going forward, so all performance related enhancements will be concentrated there and not on GDI. As for font rendering, DirectWrite renders text differently that GDI. For some users, the change in text rendering is undesirable (text appears "too blurry", "too thin"). We're working on setting up prefs that allow finer grained control over this (see bug 642589) and including more detailed information about this in the about:support page. As users play with this more, we'll see if it makes sense to adjust the default rendering parameters so that users are less apt to complain. In short, I would recommend not disabling hardware acceleration by default.
thx a lot, John. Anyone disagree? I'll mark this bug wfm in a day or so unless I hear any objections.
Thanks David and John, I'm happy with resolving this as WFM.
Assignee: nobody → dbienvenu
resolving WFM, thx again. If new evidence comes to light (e.g., beta feedback) we can always reconsider.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WORKSFORME
Depends on: 667989, 668552
One additional comment, Gecko trunk now includes support for specifying specific Cleartype rendering modes. This means that GDI classic font rendering can be achieved *without* having to disable hardware acceleration. See http://mxr.mozilla.org/mozilla-central/source/modules/libpref/src/init/all.js#1796 for more details.
Depends on: 689742
You need to log in before you can comment on or make changes to this bug.