Closed
Bug 629857
Opened 13 years ago
Closed 13 years ago
Gray bar is added after repainting layer
Categories
(Core :: Graphics, defect)
Core
Graphics
Tracking
()
RESOLVED
FIXED
Tracking | Status | |
---|---|---|
blocking2.0 | --- | final+ |
People
(Reporter: jk1700, Assigned: mattwoodrow)
References
()
Details
(Keywords: regression, testcase, Whiteboard: [softblocker], [4rc])
Attachments
(2 files, 2 obsolete files)
1.52 KB,
image/png
|
Details | |
7.92 KB,
patch
|
roc
:
review+
roc
:
approval2.0+
|
Details | Diff | Splinter Review |
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
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: --- → ?
Comment 3•13 years ago
|
||
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
Whiteboard: [softblocker]
Assignee | ||
Comment 4•13 years ago
|
||
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
Assignee | ||
Comment 6•13 years ago
|
||
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.
Assignee | ||
Comment 7•13 years ago
|
||
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.
Assignee | ||
Comment 8•13 years ago
|
||
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.
Attachment #512734 -
Flags: review?(roc)
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).
Assignee | ||
Comment 11•13 years ago
|
||
(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.
Attachment #512734 -
Attachment is obsolete: true
Attachment #514582 -
Flags: review?(roc)
Attachment #512734 -
Flags: review?(roc)
Right, I think nsDisplayTransform::TransformRect and UntransformRect need In and Out versions (although we don't necessarily need all four combinations).
Assignee | ||
Comment 13•13 years ago
|
||
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.
Attachment #514582 -
Attachment is obsolete: true
Attachment #514712 -
Flags: review?(roc)
Attachment #514582 -
Flags: review?(roc)
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+
Assignee | ||
Updated•13 years ago
|
Attachment #514712 -
Flags: approval2.0?
Attachment #514712 -
Flags: approval2.0? → approval2.0+
Assignee | ||
Comment 15•13 years ago
|
||
http://hg.mozilla.org/mozilla-central/rev/8fdc73f3e1ea
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Comment 16•13 years ago
|
||
Verified on Build identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0) Gecko/20100101 Firefox/4.0
Status: RESOLVED → VERIFIED
Comment 17•13 years ago
|
||
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 → ---
Comment 18•13 years ago
|
||
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
Updated•13 years ago
|
Whiteboard: [softblocker] → [softblocker], [4rc]
Reporter | ||
Comment 19•13 years ago
|
||
(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
Comment 20•13 years ago
|
||
Then please file a new bug, don't re-open this one.
Status: REOPENED → RESOLVED
Closed: 13 years ago → 13 years ago
Resolution: --- → FIXED
Comment 21•13 years ago
|
||
> (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.
Description
•