Gray bar is added after repainting layer

RESOLVED FIXED

Status

()

Core
Graphics
RESOLVED FIXED
8 years ago
8 years ago

People

(Reporter: gadjo, Assigned: mattwoodrow)

Tracking

({regression, testcase})

Trunk
regression, testcase
Points:
---

Firefox Tracking Flags

(blocking2.0 final+)

Details

(Whiteboard: [softblocker], [4rc], URL)

Attachments

(2 attachments, 2 obsolete attachments)

(Reporter)

Description

8 years ago
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
(Reporter)

Comment 1

8 years ago
Created attachment 508087 [details]
gray bar
(Reporter)

Updated

8 years ago
Blocks: 612846
Keywords: regression, testcase
Version: unspecified → Trunk
(Reporter)

Comment 2

8 years ago
I guess that mentioned 400ms is probably the same as in bug 628854 comment 3
(Reporter)

Updated

8 years ago
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
Whiteboard: [softblocker]
(Assignee)

Comment 4

8 years ago
I can't reproduce on OSX or windows 7. Though I am hitting bug 630835. Could be related?
(Reporter)

Comment 5

8 years ago
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

8 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

8 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

8 years ago
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.
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

8 years ago
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.
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

8 years ago
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.
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

8 years ago
Attachment #514712 - Flags: approval2.0?
(Assignee)

Comment 15

8 years ago
http://hg.mozilla.org/mozilla-central/rev/8fdc73f3e1ea
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

Updated

8 years ago
Whiteboard: [softblocker] → [softblocker], [4rc]
(Reporter)

Comment 19

8 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
Then please file a new bug, don't re-open this one.
Status: REOPENED → RESOLVED
Last Resolved: 8 years ago8 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.