Just upgraded the beta to 37.beta1. It exhibits a bug I have already seen with the latest version of Firefox. When I switch away to another window from Tb (=e.g. to Firefox or Postbox) the Thunderbird window looks completely unpainted: http://i.imgur.com/GT6U32c.png then if I do not focus to the main window but only hover over various screen elements only these get repainted: http://i.imgur.com/zkdrpQT.png When I click the main window it sometime repaints or sometimes repaints single screen elements. When I resize the window, it "flashes" (completely renders the screen elements and then makes them invisible again). Graphics Card: ATI Radeon Hd 4850 that was a quite common card when I bought it a few years back. IU know there are sometimes font rendering issues on Firefow (smidged fonts) and there was an about:config entry that would prevent this. Hoping this is something similar...
I could reproduce the same bug with Earlybird (38.0a2 (2015-03-13)) About dialiog is problematic: http://i.imgur.com/FZ5ltTD.png when I use a non-standard theme as workaround it doesn't manifest when the main window looses focus, but resizing makes the bug still appear: the client area is black and only hovered widgets are repainted: http://i.imgur.com/L0sSlXW.png Maybe this will help in determining on which Windows Repaint cycle the bug happens.
Axel, can you try to disable HW-acceleration? On TB 37 in Options/Advanced you can untick the option "Use hardware acceleration when available". On TB 36 you need to switch in "Config Editor" layers.acceleration.disabled and gfx.direct2d.disabled to true.
I tried toggling the following settings so far without success: gfx.canvas.azure.accelerated = false gfx.direct2d.disabled = true gfx.direct2d.use1_1 = false gfx.direct2d.force-enabled = true gfx.work-around-driver-bugs = false gfx.vsync.refreshdriver = false but I wonder was there a "tiles" one for ATI cards? (Can't remember the full name) also, is it possible to diff 37beta1 default prefs with 36beta1 to see what new (graphics) settings have been introduced?
Another comment - I do NOT have this issue with the current Firefox beta (Fx 37.0) but there might be helpful prefs configured in there that undo agressive screen update routines of hte new gecko engine. I will try to create new profile on that to see whether it recreates the problem there as well (assuming the platform is the same as on Tb 37beta1)
Another observation: I can avoid the error completely by turning off Aero; so there is a high probability that this is related to transparency functions on my graphics adapter / graphics driver. There must be something in the rendering that was added in this machine that either accelerates or change the method of the way native transparency is handled?
Try setting layers.acceleration.disabled to "true" (which did it for me with weird graphics issues). As for tiles, I have layers.enable-tiles "false" and layers.tiles.adjust "true" along with that. Also, why does this bug have a "blocking" severity? Doesn't look like it's universal.
(In reply to rsx11m from comment #6) > Try setting layers.acceleration.disabled to "true" (which did it for me with > weird graphics issues). tried that but it didn't resolve the issue. > As for tiles, I have layers.enable-tiles "false" and layers.tiles.adjust > "true" along with that. > > Also, why does this bug have a "blocking" severity? Doesn't look like it's > universal. Well if I do not find a workaround I will have to buy a different graphics card (and my reasoning was that the HD4850 was widely used and still has great performance without being a power hog); but I see your point so I am demoting this to "major" for now
Severity: blocker → major
(In reply to rsx11m from comment #6) > As for tiles, I have layers.enable-tiles "false" and layers.tiles.adjust > "true" along with that. > is already set to this (by default). Also I do recall that this was addressing smeared fonts, which wasn't really related. I think that this one is about transparent layers (that are behind the canvas) being refreshed or getting WM_PAINT at the wrong time. But I am not an expert with Windows Rendering. I think the only way to find out would be to "diff" the Platform, and also check if there were any new Gecko prefs added in this release?
(In reply to Axel Grude [:realRaven] from comment #4) > I will try to create new profile. Have you tried the new profile? Still the same issue?
(In reply to Richard Marti (:Paenglab) from comment #9) > (In reply to Axel Grude [:realRaven] from comment #4) > > I will try to create new profile. > > Have you tried the new profile? Still the same issue? Yes the error happens in a fresh profile as well. It is definitely caused by a change in platform (Gecko). My guess is some different hardware acceleration / transparency functionality.
I found out I can avoid the bug by checking a per-application setting in Windowblinds, called "Enable this if glass is painting with nothing on it". It is hidden away in Per application / Advanced Features. Unfortunately I did not find a way to set it globally, but I will raise a bug with Stardock support as they seem to be aware of what might trigger it.
Summary: Screen painting disabled when Thunderbird looses focus - faulty repaint → Aero Glass not painted when Thunderbird looses focus
Axel, if you can find a regression window using the Thunderbird Daily builds then that would help narrow down the change that caused this on our end. However, it's quite possible that this isn't a Thunderbird bug at all since this requires third-party software to reproduce.
Severity: major → normal
Summary: Aero Glass not painted when Thunderbird looses focus → Aero Glass not painted when Thunderbird looses focus with WindowsBlinds installed
(In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #12) > Axel, if you can find a regression window using the Thunderbird Daily builds > then that would help narrow down the change that caused this on our end. How would I go about this? Since it started with the last beta wouldn't I have to work my way backwards through builds from there towards release somehow? > However, it's quite possible that this isn't a Thunderbird bug at all since > this requires third-party software to reproduce. I am aware that it is very graphics card specific (probably much like the blurred font one, and also having Windowblinds installed to skin Windwos 7 in non standard way doesn't help). By the way Stardock promised they are working on a version that fixes the min/max/restore restore bug caused by Firefox (and possibly Tb) window frame theming. I quite like the flexibility of themes in windows 7 afforded to me by Stardock; wouldn't like the fixed layouts that are forced on users in the Mac world.
(In reply to Axel Grude [:realRaven] from comment #13) > (In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #12) > > Axel, if you can find a regression window using the Thunderbird Daily builds > > then that would help narrow down the change that caused this on our end. > > How would I go about this? Since it started with the last beta wouldn't I > have to work my way backwards through builds from there towards release > somehow? All of our past builds are on the ftp server: * 36.0b1: ftp://ftp.mozilla.org/pub/thunderbird/releases/36.0b1/ * 34.0b1: ftp://ftp.mozilla.org/pub/thunderbird/releases/34.0b1/ * 33.0b1: ftp://ftp.mozilla.org/pub/thunderbird/releases/33.0b1/ * 32.0b1: ftp://ftp.mozilla.org/pub/thunderbird/releases/32.0b1/ ... and so on. You'll want to install each of these and test them to see where the problem begins. > > > > However, it's quite possible that this isn't a Thunderbird bug at all since > > this requires third-party software to reproduce. > > I am aware that it is very graphics card specific (probably much like the > blurred font one, and also having Windowblinds installed to skin Windwos 7 > in non standard way doesn't help). By the way Stardock promised they are > working on a version that fixes the min/max/restore restore bug caused by > Firefox (and possibly Tb) window frame theming. I quite like the flexibility > of themes in windows 7 afforded to me by Stardock; wouldn't like the fixed > layouts that are forced on users in the Mac world. Fair enough, but if it's not our bug there's probably nothing we can do about it until Stardock fixes it on their end.
(In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #14) > (In reply to Axel Grude [:realRaven] from comment #13) > > (In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #12) > > > Axel, if you can find a regression window using the Thunderbird Daily builds > > > then that would help narrow down the change that caused this on our end. > > > > How would I go about this? Since it started with the last beta wouldn't I > > have to work my way backwards through builds from there towards release > > somehow? > > All of our past builds are on the ftp server: > * 36.0b1: ftp://ftp.mozilla.org/pub/thunderbird/releases/36.0b1/ > * 34.0b1: ftp://ftp.mozilla.org/pub/thunderbird/releases/34.0b1/ > * 33.0b1: ftp://ftp.mozilla.org/pub/thunderbird/releases/33.0b1/ > * 32.0b1: ftp://ftp.mozilla.org/pub/thunderbird/releases/32.0b1/ > ... and so on. You'll want to install each of these and test them to see > where the problem begins. > Oh I ran all the betas since they started. The bug started with 37.beta1. Obviously I always run the latest beta, have been doing it for a year now.
Thanks Axel, Could you narrow this down further using the 37.0a1 nightly builds? You'll find the first Thunderbird 37.0a1 build in the November 29, 2014 folder: ftp://ftp.mozilla.org/pub/thunderbird/nightly/2014/11/2014-11-29-03-02-03-comm-central/ You'll find the last Thunderbird 37.0a1 build in the January 12, 2015 folder: ftp://ftp.mozilla.org/pub/thunderbird/nightly/2015/01/2015-01-12-03-02-03-comm-central/ Keep testing builds between those dates until you narrow it down to a single day difference between a working build and a broken build. I can provide further direction as needed.
(In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #16) > Thanks Axel, > > Could you narrow this down further using the 37.0a1 nightly builds? > > You'll find the first Thunderbird 37.0a1 build in the November 29, 2014 > folder: > ftp://ftp.mozilla.org/pub/thunderbird/nightly/2014/11/2014-11-29-03-02-03- > comm-central/ > there are a lot of files in there, but the Windows ones are only around 70kBytes? Also should I install 32bit (like Firefox) even though my OS is 64bit?
Sorry, I should have given you better instructions. Please try the following builds and tell me which of them reproduce the issue. * ftp://ftp.mozilla.org/pub/thunderbird/nightly/2014/11/2014-11-25-03-02-02-comm-central/thunderbird-36.0a1.en-US.win32.installer.exe * ftp://ftp.mozilla.org/pub/thunderbird/nightly/2014/12/2014-12-05-03-02-01-comm-central/thunderbird-37.0a1.en-US.win32.installer.exe * ftp://ftp.mozilla.org/pub/thunderbird/nightly/2014/12/2014-12-09-03-02-06-comm-central/thunderbird-37.0a1.en-US.win32.installer.exe * ftp://ftp.mozilla.org/pub/thunderbird/nightly/2014/12/2014-12-17-03-02-05-comm-central/thunderbird-37.0a1.en-US.win32.installer.exe * ftp://ftp.mozilla.org/pub/thunderbird/nightly/2014/12/2014-12-24-03-02-01-comm-central/thunderbird-37.0a1.en-US.win32.installer.exe * ftp://ftp.mozilla.org/pub/thunderbird/nightly/2014/12/2014-12-31-03-02-00-comm-central/thunderbird-37.0a1.en-US.win32.installer.exe * ftp://ftp.mozilla.org/pub/thunderbird/nightly/2015/01/2015-01-07-03-02-14-comm-central/thunderbird-37.0a1.en-US.win32.installer.exe
Anthony, I have started to install the daily versions you suggested, and can confirm that the problems starts with version thunderbird-37.0a1.en-US.win32-2014-12-09-03-02-06-c-c - Version 37.0a1 (2014-12-09) Once I roll back to thunderbird-37.0a1.en-US.win32-2014-12-05-03-02-01-c-c - Version 37.0a1 (2014-12-05) the problem is gone. hth.
FWIW, bug 1149761 also cites WindowBlinds
Summary: Aero Glass not painted when Thunderbird looses focus with WindowsBlinds installed → Aero Glass not painted when Thunderbird looses focus with WindowBlinds installed
Thanks Axel, two more builds to test: * ftp://ftp.mozilla.org/pub/thunderbird/nightly/2014/12/2014-12-07-03-02-11-comm-central/thunderbird-37.0a1.en-US.win32.installer.exe * ftp://ftp.mozilla.org/pub/thunderbird/nightly/2014/12/2014-12-06-03-02-03-comm-central/thunderbird-37.0a1.en-US.win32.installer.exe
(In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #21) > Thanks Axel, two more builds to test: > > * > ftp://ftp.mozilla.org/pub/thunderbird/nightly/2014/12/2014-12-07-03-02-11- > comm-central/thunderbird-37.0a1.en-US.win32.installer.exe > * > ftp://ftp.mozilla.org/pub/thunderbird/nightly/2014/12/2014-12-06-03-02-03- > comm-central/thunderbird-37.0a1.en-US.win32.installer.exe Tested both and they are fine. Do you have one for the 8th of December as well?
I also tested the installer in ftp://ftp.mozilla.org/pub/thunderbird/nightly/2014/12/2014-12-08-03-02-08-comm-central/ and this one is fine as well. As soon as I install the build from the 9th of December the graphics problem is back. So I guess you can start diff-ing now :)
Thanks Axel, I would guess either bug 1108057 or bug 1108198 caused this regression. I've flagged the developers for those bugs, hopefully they have some insight.
status-thunderbird37: --- → affected
tracking-thunderbird37: --- → ?
Bug 1108057 is a font-size CSS change in the chat sidebar, it can't cause anything as dramatic as this.
Does this problem affect 38 too?
(In reply to aleth [:aleth] from comment #27) > Does this problem affect 38 too? Ah, sorry, I missed comment 1.
I don't think bug 1108198 caused this regression because it changes a prefs how the content colors are used and doesn't affect the window painting. And this is a copy of a FX patch. If this affects TB, then it should also affect FX. I think the regression comes from m-c with a change in the display drawing part.
(In reply to Richard Marti (:Paenglab) from comment #29) > I think the regression comes from m-c with a change in the display drawing > part. Bug 1107297 - D3D11 should only composite invalid rect
Sounds(In reply to Wayne Mery (:wsmwk, use Needinfo for questions) from comment #30) > (In reply to Richard Marti (:Paenglab) from comment #29) > > I think the regression comes from m-c with a change in the display drawing > > part. > > Bug 1107297 - D3D11 should only composite invalid rect Sounds plausible. It is a windows specific paint routine affecting rectangles... Interestingly hovering the element with the mouse invalidates the element in a way that they are properly repainted. The question is whether there is a (Dx) option in about:config which I could turn off to test whether it affects the patched version?
I think it might be just the general usage of WARP. WindowBlinds is a form of malware(yes, I'm sorry, that's really what it is, intercepting OS calls and interfering with their functioning really can't be described in any other way) that intercepts DirectX calls in a variety of way in order to achieve it goals. We've seen it interact poorly with WARP before, what's your about:support graphics section say?
ANother comment: I upgraded my graphics card to a modern Geforce 960 today and I can still reproduce the bug. So it is pretty clear to me that it is a problem with Stardock's Windowblinds. The good thing is that they have that "per application setting" which is "Enable this if glass is painting with nothing on it", so they must be aware that there is a problem with some apps. I am enabling this option for now, but I can always test again with this switched off if you need me to run any more versions.
Just to confirm that the same thing was happening to my long-standing Thunderbird install since the auto update to v38. TB was always fine before. (Win7 Nvidia GTX 295) I seem to have some recollection of something similar in the past some years ago and maybe I'd tweaked a setting or two in TB config for hardware acceleration but trying that now that made no difference to the current repainting issues. Finding this suggestion (as above) for changing a per application setting in WindowBlinds8 did the trick for me and now the redraw failures and blackouts of TB have now stopped. In main TB releases, it was definitely a change in v38 that brought the problem out for me.
Based on comment 32 and comment 34 it sounds like this is stardock's issue, so closing invalid. bug 982362 is also Axel's
Status: NEW → RESOLVED
Last Resolved: 3 years ago
tracking-thunderbird37: ? → ---
Resolution: --- → INVALID
See Also: → bug 982362
You need to log in before you can comment on or make changes to this bug.