User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b11pre) Gecko/20110127 Firefox/4.0b11pre Build Identifier: This is regression from bug 612846 http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=d55f25baadb3&tochange=8bb432a920fe Reproducible: Always Steps to Reproduce: 1. Open url 2. Move mouse cursor in and out from the content area Actual Results: When scale is changed to 1.0 the grey bar appears on the right (it happens after about 400ms) Expected Results: No grey bar should appear
Keywords: regression, testcase
Version: unspecified → Trunk
I guess that mentioned 400ms is probably the same as in bug 628854 comment 3
Summary: Gray bar is added after repaiting layer → Gray bar is added after repainting layer
blocking2.0: --- → ?
This happens on OS X too.
Assignee: nobody → matt.woodrow+bugzilla
Status: UNCONFIRMED → NEW
blocking2.0: ? → final+
Ever confirmed: true
OS: Windows 7 → All
Hardware: x86 → All
I can't reproduce on OSX or windows 7. Though I am hitting bug 630835. Could be related?
I still can see the effect, here is my graphics details (in polish, but think it's obvious what's what), maybe it will help in investigation: Opis adaptera ATI Radeon HD 3800 Series ID dostawcy 1002 ID urządzenia 9505 RAM adaptera 512 Sterowniki adaptera aticfx64 aticfx64 aticfx32 aticfx32 atiumd64 atidxx64 atiumdag atidxx32 atiumdva atiumd6a atitmm64 Wersja sterownika 8.812.0.0 Data sterownika 1-4-2011 Włączone Direct2D true Włączone DirectWrite true (6.1.7600.20830, font cache n/a) Renderer WebGL Google Inc. -- ANGLE -- OpenGL ES 2.0 (ANGLE 0.0.0.541) Okna ze sprzętowym przyspieszeniem grafiki 1/1 Direct3D 10
I can reproduce this (intermittently) on the 2011-01-26 nightly which is before the listed regression range. I'll try find a new one. Since this happens 400ms after the transition, it's likely a bug with BasicLayers (as the layer becomes inactive) and unrelated to the D3D10 change.
Looks like this is the regression range: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=6a097e294828&tochange=e0fc18b3bc41 Before this invalidation was entirely broken, after this just the grey bar.
Created attachment 512734 [details] [diff] [review] Possible Fix. Looks like this was the relevant change: http://hg.mozilla.org/mozilla-central/rev/bbf235e368ed The full size rect measures as 190 onscreen pixels (using an external tool), yet we are passing 187 as the width inside InvalidateTransformLayer. I really don't know this code well enough to say this is the correct fix, but snapping the unscaled size outwards to the nearest pixel before transforming it fixes the reported issue.
Hmm. I think we should split MatrixTransformRect into MatrixTransformRectIn and MatrixTransformRectOut and use the "correct" versions everywhere.
Another thing that's probably worth doing is calling NSAppUnitsToDoublePixels instead of NSAppUnitsToFloatPixels (and adding an NSAppUnitsToDoublePixels overload that takes a double parameter for aFactor).
Created attachment 514582 [details] [diff] [review] Fix v2 (In reply to comment #9) > Hmm. I think we should split MatrixTransformRect into MatrixTransformRectIn and > MatrixTransformRectOut and use the "correct" versions everywhere. What are the correct times to use each of these? MatrixTransformRect only has two callers, nsDisplayTransform::TransformRect, and UntransformRect. Changing the code to round out in either MatrixTransformRect or TransformRect causes reflow to be affected and we get test failures. This patch moves the fix up into InvalidateInternal so that only invalidation is affected, and passes reftests on try.
Right, I think nsDisplayTransform::TransformRect and UntransformRect need In and Out versions (although we don't necessarily need all four combinations).
Created attachment 514712 [details] [diff] [review] Fix v3 Creates RoundOut, but not RoundIn. I don't see any use case for RoundIn currently, and I'd be very hesistant to touch anything that will affect reflow (partially because I know nothing about it) at this point in the release cycle. I think we'd be better leaving the current version (no rounding before transformation) and filing a follow-up to handle anything else. I'll push this to tryserver tonight unless I hear otherwise.
Comment on attachment 514712 [details] [diff] [review] Fix v3 RoundGfxRectToAppRect should be renamed to use the word "Out" somehow. Let's do that in another patch.
Attachment #514712 - Flags: review?(roc) → review+
Attachment #514712 - Flags: approval2.0?
Attachment #514712 - Flags: approval2.0? → approval2.0+
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
Verified on Build identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0) Gecko/20100101 Firefox/4.0
Status: RESOLVED → VERIFIED
Reopening because on Windows and Linux works fine, but i still see it on MacOS X 10.6 Build identifier: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0) Gecko/20100101 Firefox/4.0
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Can it be this bug or should I file a new one? when hovering any tab - a tooltip appears, but it gets drawn by 2 stages: 1. first only the left part is painted correctly, and the right part is grey 2. then right part gets painted too. So the process of showing the tooltip is 2-staged, like 2 frames instead of 1. However, there's about 100ms between them, so it's quite fast, but still notable for the eyes. P4 3.0Ghz, Win7sp1, HD3850 series, DW = on, D2D = on
(In reply to comment #18) > Can it be this bug or should I file a new one? > when hovering any tab - a tooltip appears, but it gets drawn by 2 stages: > 1. first only the left part is painted correctly, and the right part is grey > 2. then right part gets painted too. I don't think it's a same issue BTW - I can see still the original bug on Windows 7 in 20110307 build
Then please file a new bug, don't re-open this one.
Status: REOPENED → RESOLVED
Last Resolved: 8 years ago → 8 years ago
Resolution: --- → FIXED
> (In reply to comment #19) > I don't think it's a same issue > > BTW - I can see still the original bug on Windows 7 in 20110307 build so should I file a new bug or maybe it's a known issue? p.s. for *: You need to stop banning my accounts and unban my IP if you want me to take less racist nick-names.
You need to log in before you can comment on or make changes to this bug.