Closed Bug 629857 Opened 13 years ago Closed 13 years ago

Gray bar is added after repainting layer

Categories

(Core :: Graphics, defect)

defect
Not set
normal

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)

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
Attached image gray bar
Blocks: 612846
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
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]
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.
Attached patch Possible Fix. (obsolete) — Splinter Review
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).
Attached patch Fix v2 (obsolete) — Splinter Review
(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).
Attached patch Fix v3Splinter Review
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+
Attachment #514712 - Flags: approval2.0?
http://hg.mozilla.org/mozilla-central/rev/8fdc73f3e1ea
Status: NEW → RESOLVED
Closed: 13 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
Whiteboard: [softblocker] → [softblocker], [4rc]
(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
Closed: 13 years ago13 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.