Stop using Thebes surfaces for masking in BasicLayers

RESOLVED FIXED in mozilla31

Status

()

defect
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: mattwoodrow, Assigned: mattwoodrow)

Tracking

Trunk
mozilla31
x86
macOS
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(5 attachments)

Assignee

Description

5 years ago
This a subset of bug 989858, and is blocking jwatt's conversion of imgIContainer::GetFrame.
Assignee

Updated

5 years ago
Assignee: nobody → matt.woodrow
Assignee

Comment 2

5 years ago
I guess this isn't ideal, but it's a lot easier than converting all of BasicLayers and lets us unblock jwatt's work. This can go away again once all the things are done.
Attachment #8403684 - Flags: review?(roc)
Assignee

Comment 3

5 years ago
We're already requiring Moz2D backed gfxContexts for BasicLayers. This just avoids converting our Moz2D surface into a thebes one and then back again.
Attachment #8403685 - Flags: review?(roc)
Assignee

Comment 4

5 years ago
And this removes the last user of the 'deprecated' surfaces on Image, which makes the world a happier place.
Attachment #8403686 - Flags: review?(roc)
Comment on attachment 8403684 [details] [diff] [review]
Add gfxContext API to avoid converting between moz2d and thebes needlessly

Review of attachment 8403684 [details] [diff] [review]:
-----------------------------------------------------------------

::: gfx/thebes/gfxContext.cpp
@@ +1514,5 @@
>  
>      if (!sourceSurf) {
>        return;
>      }
> +  

trailing whitespace

@@ +1528,5 @@
> +  MOZ_ASSERT(mDT);
> +
> +
> +  // We clip here to bind to the mask surface bounds, see above.
> +  mDT->MaskSurface(GeneralPattern(this), 

trailing whitespace
Attachment #8403684 - Flags: review?(roc) → review+
After installing this patch on inbound I get massive graphic corruption when I scroll.  I did a regression test and narrowed it down to this patch.

I'm running Windows 8.1.1.
Graphics
--------

Adapter Description: AMD Radeon HD 7900 Series
Adapter Drivers: aticfx64 aticfx64 aticfx64 aticfx32 aticfx32 aticfx32 atiumd64 atidxx64 atidxx64 atiumdag atidxx32 atidxx32 atiumdva atiumd6a atitmm64
Adapter RAM: 3072
Device ID: 0x6798
Direct2D Enabled: true
DirectWrite Enabled: true (6.3.9600.16384)
Driver Date: 12-6-2013
Driver Version: 13.251.0.0
GPU #2 Active: false
GPU Accelerated Windows: 1/1 Direct3D 11 (OMTC)
Vendor ID: 0x1002
WebGL Renderer: Google Inc. -- ANGLE (AMD Radeon HD 7900 Series Direct3D9Ex vs_3_0 ps_3_0)
windowLayerManagerRemote: true
AzureCanvasBackend: direct2d
AzureContentBackend: direct2d
AzureFallbackCanvasBackend: cairo
AzureSkiaAccelerated: 0
Turning off HWA produces no corruption.
Posted image Corruption
FYI... Left HWA enabled and turned off OMTC and there is no corruption.
Blocks: 982427
No longer blocks: 950372
Blocks: 960524
No longer blocks: 982427
Any confirmation of my findings?
Assignee

Comment 13

5 years ago
Are you sure it's this bug? I strongly suspect you're seeing something related to Bug 992486 (which landed at the same time).
I could only find this patch when I did my regression testing using the inbounds.  I can't find the files that contain 992486.  Is there a separate file that contains 992486 and not 993784?
Assignee

Comment 15

5 years ago
No there isn't, sorry. I can have a look locally I guess.
If the file I used on inbound contains both patches then it's a toss up as to which one is causing my problem. I'm just trying to prevent a bad patch from hitting Nightly.
Assignee

Comment 17

5 years ago
I reproduced this locally, it is indeed bug 992486. I'll fix it.
You need to log in before you can comment on or make changes to this bug.