Closed
Bug 623852
Opened 14 years ago
Closed 14 years ago
[OS X] [Hardware acceleration off] Websites flickering, partially dis- and reappearing, tabs missing
Categories
(Core :: Graphics, defect)
Tracking
()
RESOLVED
FIXED
mozilla2.0b10
Tracking | Status | |
---|---|---|
blocking2.0 | --- | betaN+ |
People
(Reporter: nikarlo, Assigned: roc)
References
Details
(Keywords: regression, Whiteboard: [hardblocker])
Attachments
(1 file)
3.66 KB,
patch
|
mstange
:
review+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b9pre) Gecko/20110106 Firefox/4.0b9pre Build Identifier: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b9pre) Gecko/20110106 Firefox/4.0b9pre Tabs are white (empty) when scrolling and when I select one of them sometimes doesn't work and still to last selected tab. The same also with a new profile. Reproducible: Always
Comment 1•14 years ago
|
||
Please run Firefox in Safe Mode (http://support.mozilla.com/en-US/kb/Safe Mode) to make sure no extension is causing this issue. Further please try to disable hardware acceleration in the advanced pane of the preferences. Would be nice if you could post the graphic card information from the Help | Troubleshooting page. Thanks.
Hardware: Other → x86_64
Version: unspecified → Trunk
In safe mode is the same. This is my graph info: Adapter Description0x22400,0x20400 Vendor ID0000 Device ID0000 Adapter RAM Adapter DriversDriver VersionDriver DateDirect2D EnabledfalseDirectWrite EnabledfalseWebGL RendererNVIDIA Corporation -- NVIDIA GeForce 7600 GS OpenGL Engine -- 2.1 NVIDIA-1.6.26GPU Accelerated Windows0/1 Machine is a osx86 with retail snow leopard
Comment 3•14 years ago
|
||
I'm changing the summary to the one from bug 622901, which is the same issue.
Status: UNCONFIRMED → NEW
Component: Tabbed Browser → Graphics
Ever confirmed: true
Product: Firefox → Core
QA Contact: tabbed.browser → thebes
Summary: Tab is not show if scrolling, most of tabs is white and take time to show → [OS X] [Hardware acceleration off] Websites flickering, partially dis- and reappearing
Updated•14 years ago
|
blocking2.0: --- → ?
Keywords: regression,
regressionwindow-wanted
Updated•14 years ago
|
Summary: [OS X] [Hardware acceleration off] Websites flickering, partially dis- and reappearing → [OS X] [Hardware acceleration off] Websites flickering, partially dis- and reappearing, tabs missing
How I can help you? I must try to compile myself from a trunk?
Comment 9•14 years ago
|
||
Ran into this problem and tested it on nightlies. Showed up in 2011-01-03 but not in 2011-01-02. A similar issue, a line between the title bar and tab bar flickered showed up in 2011-01-02 though.
Comment 10•14 years ago
|
||
(In reply to comment #9) > A similar issue, a line between the title bar and tab bar flickered showed up > in 2011-01-02 though. That's bug 621762.
Comment 11•14 years ago
|
||
I've bisected the checkins in the range, this is the cause of the regression: http://hg.mozilla.org/mozilla-central/rev/b7d1bb50e829
Blocks: 363861
Keywords: regressionwindow-wanted
Comment 12•14 years ago
|
||
The bug originates in PushGroupAndCopyBackground (called from BasicThebesLayer::Paint): the call to cairo_paint fails. After that the context gets marked as being in an error state and everything falls apart. The problem seems to be that we're trying to use a surface as source which can't be used in that way. Specifically, the surface "s" is the one we've constructed in -[ChildView drawRect:inContext:] (called "targetSurface" there) - in other words, it's the window buffer. However, the cairo quartz backend can only use offscreen buffers ("bitmap contexts") as source surfaces. I don't know if there's a way at all to read back the pixels we've drawn into the window.
Assignee | ||
Comment 14•14 years ago
|
||
I see. I guess we'll need to predict in advance whether we'll need PushGroupAndCopyBackground and if we will, use a manual backbuffer.
Assignee | ||
Comment 16•14 years ago
|
||
Actually the thing to do is allow PushGroupAndCopyBackground to fall back to just PushGroup if we can't copy the background. That's the conservative fix for the regression here.
Assignee | ||
Updated•14 years ago
|
Assignee: nobody → roc
Comment 17•14 years ago
|
||
I pasted a lot of info into Bug 623373 https://bugzilla.mozilla.org/show_bug.cgi?id=623373 - but yes both are the same bug
Assignee | ||
Comment 18•14 years ago
|
||
This should fix it, although I don't have my Mac at home so I can't test it right now. I wonder why this doesn't cause reftests to fail with acceleration off.
Attachment #502455 -
Flags: review?(mstange)
Assignee | ||
Updated•14 years ago
|
Whiteboard: [needs review]
Assignee | ||
Comment 19•14 years ago
|
||
tryserver build will appear at http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/rocallahan@mozilla.com-cabf467b8766
Reporter | ||
Comment 20•14 years ago
|
||
(In reply to comment #19) > tryserver build will appear at > http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/rocallahan@mozilla.com-cabf467b8766 I can't find your directory
Comment 21•14 years ago
|
||
(In reply to comment #18) > This should fix it, although I don't have my Mac at home so I can't test it > right now. Yes, this fixes it. + if (s->GetAllowUseAsSource() && + (s->GetContentType() == gfxASurface::CONTENT_COLOR || + s->GetOpaqueRect().Contains(GetRoundOutDeviceClipExtents(this)))) { I think instead of s->GetAllowUseAsSource() you need (s->GetAllowUseAsSource() || s->GetType() == gfxASurface::SurfaceTypeTee), otherwise the tee surface case further down won't ever be reached. > I wonder why this doesn't cause reftests to fail with acceleration off. Probably because reftests draw into a canvas, not into the window. I don't think the gfxQuartzSurface.cpp hunk was supposed to be part of the patch.
Comment 22•14 years ago
|
||
Comment on attachment 502455 [details] [diff] [review] fix r=me with the comments addressed
Attachment #502455 -
Flags: review?(mstange) → review+
Assignee | ||
Updated•14 years ago
|
Whiteboard: [needs review] → [needs landing]
Updated•14 years ago
|
Whiteboard: [needs landing] → [needs landing][hardblocker]
Comment 25•14 years ago
|
||
I think that this bug might be also what I'm seeing as the regression range is also from 2011-01-02 to 2011-01-03: Loading a dialog in CKEditor for the second time doesn't show up until the page is clicked. Load http://ckeditor.com/demo and click for example in the smiley dialog, the first time behaves more or less correctly, but the second one will fail. This fails in my macbook and works correctly in XP
Assignee | ||
Comment 27•14 years ago
|
||
http://hg.mozilla.org/mozilla-central/rev/4c3416fdc7b0
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Whiteboard: [needs landing][hardblocker] → [hardblocker]
Updated•14 years ago
|
Target Milestone: --- → mozilla2.0b10
Reporter | ||
Comment 29•14 years ago
|
||
I still have the same problem with the latest release of Minefield 4.0 b10 pre
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Reporter | ||
Comment 31•14 years ago
|
||
(In reply to comment #30) > What changeset ID in about:config? 3d4620449437
Assignee | ||
Comment 32•14 years ago
|
||
That changeset doesn't have this patch. Try the next nightly build.
Status: REOPENED → RESOLVED
Closed: 14 years ago → 14 years ago
Resolution: --- → FIXED
Comment 35•14 years ago
|
||
I think Bug 626211 may be a dupe of this. This is how Twitter.com appears in FF4 B9: http://screencast.com/t/D88TCC1hTJme Fixed in subsequent Minefield builds for me.
Reporter | ||
Comment 37•14 years ago
|
||
(In reply to comment #32) > That changeset doesn't have this patch. Try the next nightly build. is the same also on build 20110117033243
You need to log in
before you can comment on or make changes to this bug.
Description
•