Closed Bug 942688 Opened 6 years ago Closed 3 years ago

Draw Cocoa Widget without assuming DrawTargetCG

Categories

(Core :: Widget: Cocoa, defect, P3)

x86
macOS
defect

Tracking

()

RESOLVED FIXED
mozilla51

People

(Reporter: gal, Assigned: mchang)

References

Details

(Whiteboard: [leave open][tpi:+])

Attachments

(2 files, 15 obsolete files)

4.79 KB, patch
mchang
: review+
Details | Diff | Splinter Review
1.82 KB, patch
mstange
: review+
Details | Diff | Splinter Review
We currently draw the title bar by creating a CG draw target and then we borrow the CGContext from it to let the OS draw the title bar into it. Instead, directly create a CGContext and then draw the bitmap as data source surface. This is required so we can delete DrawTargetCG.
Assignee: nobody → gal
Attachment #8337527 - Flags: review?(jmuizelaar)
Summary: draw title bar without azure → draw cocoa widget without azure
Attachment #8337527 - Attachment description: patch → Part 1: Draw title bar decoration with Azure.
Summary: draw cocoa widget without azure → Draw Cocoa Widget with Azure
Summary: Draw Cocoa Widget with Azure → Draw Cocoa Widget without assuming DrawTargetCG
Attachment #8337527 - Attachment description: Part 1: Draw title bar decoration with Azure. → Part 1: Draw title bar decoration with CG directly.
Attachment #8337552 - Flags: review?(jmuizelaar)
Comment on attachment 8337552 [details] [diff] [review]
Part 2: Draw corner mask with Azure.

>diff --git a/widget/cocoa/nsChildView.mm b/widget/cocoa/nsChildView.mm
>--- a/widget/cocoa/nsChildView.mm
>+++ b/widget/cocoa/nsChildView.mm
>@@ -2357,19 +2357,22 @@ nsChildView::MaybeDrawRoundedCorners(GLM
> 
>   if (!mCornerMaskImage) {
>     mCornerMaskImage = new RectTextureImage(aManager->gl());
>   }
> 
>   nsIntSize size(mDevPixelCornerRadius, mDevPixelCornerRadius);
>   mCornerMaskImage->UpdateIfNeeded(size, nsIntRegion(), ^(gfx::DrawTarget* drawTarget, const nsIntRegion& updateRegion) {
>     ClearRegion(drawTarget, updateRegion);
>-    gfx::BorrowedCGContext borrow(drawTarget);
>-    DrawTopLeftCornerMask(borrow.cg, mDevPixelCornerRadius);
>-    borrow.Finish();
>+    RefPtr<gfx::PathBuilder> builder = drawTarget->CreatePathBuilder();
>+    builder->Arc(gfx::Point(mDevPixelCornerRadius, mDevPixelCornerRadius), mDevPixelCornerRadius, 0, 2.0f * M_PI);
>+    RefPtr<gfx::Path> path = builder->Finish();
>+    drawTarget->Fill(path,
>+                     gfx::ColorPattern(gfx::Color(1.0, 1.0, 1.0, 1.0)),
>+                     gfx::DrawOptions(1.0f, gfx::OP_SOURCE));
>   });
> 
>   // Use operator destination in: multiply all 4 channels with source alpha.
>   aManager->gl()->fBlendFuncSeparate(LOCAL_GL_ZERO, LOCAL_GL_SRC_ALPHA,
>                                      LOCAL_GL_ZERO, LOCAL_GL_SRC_ALPHA);
> 
>   gfx3DMatrix flipX = gfx3DMatrix::ScalingMatrix(-1, 1, 1);
>   gfx3DMatrix flipY = gfx3DMatrix::ScalingMatrix(1, -1, 1);
Attachment #8337552 - Attachment is patch: true
Attachment #8337552 - Attachment mime type: text/x-patch → text/plain
Resizers were dropped in 10.7 and up and we are about to drop 10.6 support anyway, so probably good timing to delete this. Tiny regression for a handful users on 10.6 at this point.
Attachment #8337564 - Flags: review?(jmuizelaar)
Attachment #8337572 - Flags: review?(jmuizelaar)
With this we should be able to use skia to render the UI on cocoa.
Attachment #8337582 - Flags: review?(jmuizelaar)
I can do the reviews here if you'd like me to. I think Jeff is still on vacation.
Attachment #8337853 - Flags: review?(jmuizelaar)
Comment on attachment 8337527 [details] [diff] [review]
Part 1: Draw title bar decoration with CG directly.

Looks good except for the clipping issue.

>diff --git a/widget/cocoa/nsChildView.mm b/widget/cocoa/nsChildView.mm

> nsChildView::UpdateTitlebarImageBuffer()

>+
>+  CGContextSaveGState(ctx);
>+
>+  nsIntRegionRectIterator iter(dirtyTitlebarRegion);
>+  for (;;) {
>+    const nsIntRect* r = iter.Next();
>+    if (!r)
>+      break;
>+    CGContextClipToRect(ctx, CGRectMake(r->x, r->y, r->width, r->height));
>+  }

This will set the clip to the intersection of the rects, not to the union. You'll need to use CGContextClipToRects.

> void
>+RectTextureImage::UpdateFromCGContext(const nsIntSize& aNewSize,
>+                                      const nsIntRegion& aDirtyRegion,
>+                                      CGContextRef aCGContext)
>+{
>+  gfx::IntSize size = gfx::IntSize(CGBitmapContextGetWidth(aCGContext),
>+                                   CGBitmapContextGetHeight(aCGContext));
>+  mBufferSize.SizeTo(size.width, size.height);
>+  RefPtr<gfx::DrawTarget> dt = BeginUpdate(aNewSize, aDirtyRegion);
>+  if (dt) {
>+    gfx::Rect rect(0, 0, size.width, size.height);
>+    gfxUtils::ClipToRegion(dt, GetUpdateRegion());
>+    RefPtr<gfx::SourceSurface> sourceSurface =
>+      dt->CreateSourceSurfaceFromData(static_cast<uint8_t *>(CGBitmapContextGetData(aCGContext)),
>+                                      size,
>+                                      size.width * 4,
>+                                      gfx::FORMAT_B8G8R8A8);

I'd prefer CGBitmapContextGetBytesPerRow instead of size.width * 4.

This will make a copy of the data. Using Factory::CreateWrappingDataSourceSurface would be better, but calling DrawSurface with that won't work with DrawTargetCG or DrawTargetSkia until bug 930956 resp. bug 924102 comment 51 land. I hope that's going to happen tomorrow.
Attachment #8337527 - Flags: review?(jmuizelaar) → review-
Attachment #8337552 - Flags: review?(jmuizelaar) → review+
Comment on attachment 8337564 [details] [diff] [review]
Part 3: Remove code to draw resizers.

Over one third of our Mac users are on 10.6 according to http://armenzg.blogspot.de/2013/11/re-thinking-our-mac-os-x-continuous.html . Do we really want to do this?
Comment on attachment 8337572 [details] [diff] [review]
Part 4: Native drawing with CGContext borrowing.

This is intentionally regressing native theme drawing performance with content CG Azure, yes?
If this passes Talos, fine, but I expect it won't.

If our current DrawTarget is a Skia software DrawTarget, we should be able to rewrap the backing data in a short-lived CGContext.
Attachment #8337572 - Flags: review?(jmuizelaar) → review+
Attachment #8337582 - Flags: review?(jmuizelaar) → review+
Attachment #8337853 - Flags: review?(jmuizelaar) → review+
Attached patch rollup patch for mstange (obsolete) — Splinter Review
Depends on: 943084
Attachment #8338105 - Flags: review?(mstange)
Attachment #8338026 - Attachment is obsolete: true
Comment on attachment 8337564 [details] [diff] [review]
Part 3: Remove code to draw resizers.

This is a lot of work for 10.6 users to see a resizer, even given our significant population of 10.6 users.  Let's take it out and see if we hear any complaints; I suspect that we won't -- people will still grab the window by the corner and resize, and it will just work.
Attachment #8337564 - Flags: review?(jmuizelaar) → review+
Starting with 10.7 all windows have rounded rects so we can as well not do this nonsense (and the next patch depends on this new behavior).
Attachment #8338334 - Flags: review?(mstange)
Attached patch Part 8: Always enable OMTC. (obsolete) — Splinter Review
This always enables OMTC. In drawRect we fill the pixel buffer with a solid rect (minus the corners) to ensure a shadow is visible.

Note: The context menu has a shadow now and the outline has the right size, but we still only render a quad of it. That bug is still there.
Attachment #8338335 - Flags: review?(mstange)
Attachment #8338105 - Flags: review?(mstange) → review+
Comment on attachment 8338334 [details] [diff] [review]
Part 7: Always render rounded rects.

The benefit of removing these methods is extremely questionable. And doesn't this give tooltips rounded corners, too? Let's not do that.
I also expect this to cut off rounded corners directly *under* the titlebar in windows that do not cover the titlebar, like the bookmarks manager (Cmd+Shift+B).
Attachment #8338334 - Flags: review?(mstange) → review-
Comment on attachment 8338335 [details] [diff] [review]
Part 8: Always enable OMTC.

>diff --git a/widget/cocoa/nsChildView.mm b/widget/cocoa/nsChildView.mm

>+// We fill the contents of the rest of the pixel buffer with opaque pixels to
>+// ensure that the shadow is drawn, even though the actual pixels will be all
>+// covered by opaque pixels rendered by OpenGL.

The last part is actually not true. That's a real problem with this approach, and it only occurred to me yesterday after I had already left: Both tooltips and context menus are *not* completely opaque on the inside. They are slightly transparent. Filling the background with opaque white will make them completely opaque and will make us look less like a native app. If that's the price to pay, OK, but I'd really like to avoid it.
I'll now try to find out whether there are ways to prevent the opaque rounded rect from reaching the screen if there's a GL context on top of it.

The reason that shadows worked for not-completely-opaque context menus is that there's a certain alpha threshold that determines for each pixel whether it has a shadow. I don't know the threshold at the moment, but I'll find that out, too, and then we can limit ourselves to that alpha value so that there's at least a bit of transparency left.

> // Making the corners transparent works even though our window is
> // declared "opaque" (in the NSWindow's isOpaque method).
>-- (void)clearCorners
>-{
>+- (void)clearBackground
>+{
>+  [[NSColor colorWithDeviceWhite:1.0 alpha:1.0] set];
>+  NSRectFill(NSMakeRect(0, 0, [self bounds].size.width, [self bounds].size.height));

This can just be NSRectFill([self bounds]);. And doing this for opaque windows is wasteful, so I'd wrap it in an if (![[self window] isOpaque]).
Comment on attachment 8338334 [details] [diff] [review]
Part 7: Always render rounded rects.

For determining the rounded corner shape of popup windows, we'll probably want a new nsIWidget API that sets the shape based on the -moz-appearance value of the root frame of the popup, so that for -moz-appearance: tooltip we get square corners and for -moz-appearance: menupopup we get round corners, for example. I'll write the patch.
Comment on attachment 8338335 [details] [diff] [review]
Part 8: Always enable OMTC.

This approach also does not work for the Australis hamburger button panel, which draws a more complicated shape with an arrow on top. This panel does not supply its own shadow, so if we blindly always draw the shadow for a rounded rect, this panel will look very wrong.

Let's file a new bug about using GL+OMTC for popups. Figuring that out is going to take some work and should not block landing the other patches here.
Attachment #8338335 - Flags: review?(mstange) → review-
Attachment #8337527 - Attachment is obsolete: true
Comment on attachment 8337564 [details] [diff] [review]
Part 3: Remove code to draw resizers.

>diff --git a/widget/cocoa/nsChildView.h b/widget/cocoa/nsChildView.h
>--- a/widget/cocoa/nsChildView.h
>+++ b/widget/cocoa/nsChildView.h
>@@ -469,17 +469,16 @@ public:
> 
>   virtual int32_t         RoundsWidgetCoordinatesTo() MOZ_OVERRIDE;
> 
>   NS_IMETHOD              Invalidate(const nsIntRect &aRect);
> 
>   virtual void*           GetNativeData(uint32_t aDataType);
>   virtual nsresult        ConfigureChildren(const nsTArray<Configuration>& aConfigurations);
>   virtual nsIntPoint      WidgetToScreenOffset();
>-  virtual bool            ShowsResizeIndicator(nsIntRect* aResizerRect);

Note that this change will also regress bug 56488 on 10.6: Scrollbars will no longer leave space for the resizer, which causes clicks to the down scroll arrow to be blocked. I definitely expect bugs to be filed about that problem.
Yeah totally agree that 7- should be fixed separately.
I saw a failure that might be the switch to skia so another run without the skia switch:

https://tbpl.mozilla.org/?tree=Try&rev=b1952b02a5c1
I can confirm a problem with part 4 locally.
Man the try server build times are really ridiculous these days.
Landed the first two parts on inbound:

https://hg.mozilla.org/integration/mozilla-inbound/rev/f90c68af9d88
https://hg.mozilla.org/integration/mozilla-inbound/rev/7e5eab057928

Local testing passed. Crossing my fingers.

Part 3 fails locally. Working on that.
(In reply to Markus Stange [:mstange] from comment #22)
> Comment on attachment 8337564 [details] [diff] [review]
> Part 3: Remove code to draw resizers.
> 
> >diff --git a/widget/cocoa/nsChildView.h b/widget/cocoa/nsChildView.h
> >--- a/widget/cocoa/nsChildView.h
> >+++ b/widget/cocoa/nsChildView.h
> >@@ -469,17 +469,16 @@ public:
> > 
> >   virtual int32_t         RoundsWidgetCoordinatesTo() MOZ_OVERRIDE;
> > 
> >   NS_IMETHOD              Invalidate(const nsIntRect &aRect);
> > 
> >   virtual void*           GetNativeData(uint32_t aDataType);
> >   virtual nsresult        ConfigureChildren(const nsTArray<Configuration>& aConfigurations);
> >   virtual nsIntPoint      WidgetToScreenOffset();
> >-  virtual bool            ShowsResizeIndicator(nsIntRect* aResizerRect);
> 
> Note that this change will also regress bug 56488 on 10.6: Scrollbars will
> no longer leave space for the resizer, which causes clicks to the down
> scroll arrow to be blocked. I definitely expect bugs to be filed about that
> problem.

How would the code I removed affect the scrollbar size?
Flags: needinfo?(mstange)
Part 3 actually passes too but mstange had concerns about the scroll bar.
Never mind found it.

/layout/generic/nsGfxScrollFrame.cpp (View Hg log or Hg annotations)
line 3854 -- if (!widget || !widget->ShowsResizeIndicator(&widgetRect))
Flags: needinfo?(mstange)
I put the ShowsResizer part back without actually drawing them. That should fix the issue mstange reported. I won't land until the current stuff goes green.
Attachment #8338335 - Attachment is obsolete: true
Attachment #8338334 - Attachment is obsolete: true
I had to fix a couple of random bugs my patch tickled:

+  nativeDirtyRect.Round();

We were rounding the native widget rect but not the dirty rect, which was cutting off widget painting by 1 pixel. Fun stuff.

This one was even better:

+  if (nativeDirtyRect.IsEmpty())

We were checking whether the widget rect was empty. Instead we have to check whether the dirty rect is empty, otherwise CGContextCreate returns null because width or height are 0 and we barf somewhere else.

I put this one back in, mostly because I am terrified of removing it:

+    // bug 382049 - need to explicity set the composite operation to sourceOver
+    CGContextSetCompositeOperation(mCGContext, kPrivateCGCompositeSourceOver);

Ditto for this one:

+    CGContextSetInterpolationQuality(mCGContext, kCGInterpolationLow);

Turns out CG's coordinate system is y-flipped, this one fixes that:

+    CGContextTranslateCTM(mCGContext, 0, backingSize.height);
+    CGContextScaleCTM(mCGContext, 1.0, -1.0);
Attachment #8339671 - Flags: review?
Need a follow-up to use moz2d to composite the CG bitmap, asserting that we always have a draw target.
Comment on attachment 8339671 [details] [diff] [review]
Part 4: Native drawing with CGContext borrowing.

mattwoodrow is concerned about regressing UI paint performance since we go through an intermediary texture now instead of borrowing the context. I was arguing that the widgets we render tend to be small, and we memcpy that onto the actual surface, so it should be fast.
Attachment #8339671 - Flags: review? → review?(mstange)
Attachment #8337572 - Attachment is obsolete: true
Attachment #8339671 - Attachment is obsolete: true
Attachment #8339671 - Flags: review?(mstange)
Attachment #8339806 - Flags: review?(mstange)
Comment on attachment 8339806 [details] [diff] [review]
Part 4: Native drawing without CGContext borrowing.

>diff --git a/gfx/thebes/gfxQuartzNativeDrawing.cpp b/gfx/thebes/gfxQuartzNativeDrawing.cpp
>+    // Copy back to destination
>+    mDT->DrawSurface(data,
>+                     mozilla::gfx::Rect(mNativeRect.x, mNativeRect.y, mNativeRect.width, mNativeRect.height),

gfx2DGlue.h has a ToRect() helper that takes a gfxRect and turns it into a gfx::Rect.

>diff --git a/widget/reftests/reftest.list b/widget/reftests/reftest.list
>--- a/widget/reftests/reftest.list
>+++ b/widget/reftests/reftest.list
>@@ -1,6 +1,6 @@
> skip-if(!cocoaWidget) != 507947.html about:blank
> == progressbar-fallback-default-style.html progressbar-fallback-default-style-ref.html
>-fuzzy-if(Android,17,1120) == meter-native-style.html meter-native-style-ref.html
>-skip-if(!cocoaWidget) == meter-vertical-native-style.html meter-vertical-native-style-ref.html # dithering
>+fuzzy-if(Android,17,1120) fuzzy-if(cocoaWidget,1,655) == meter-native-style.html meter-native-style-ref.html
>+skip-if(!cocoaWidget) fuzzy-if(cocoaWidget,2,5010) == meter-vertical-native-style.html meter-vertical-native-style-ref.html # dithering

Do we know what causes this? Different transparency blending? Or are we compositing with a fractional offset, or a slightly wrong size?

My r+ is conditional on this not regressing Talos numbers, as always.
Attachment #8339806 - Flags: review?(mstange) → review+
(In reply to Andreas Gal :gal from comment #37)
> Comment on attachment 8339671 [details] [diff] [review]
> Part 4: Native drawing with CGContext borrowing.
> 
> mattwoodrow is concerned about regressing UI paint performance since we go
> through an intermediary texture now instead of borrowing the context. I was
> arguing that the widgets we render tend to be small, and we memcpy that onto
> the actual surface, so it should be fast.

I'm concerned about that, too. But if it's a problem, it should be caught by our Talos tests, especially by tresize or TART. In tresize, we repaint the whole window on every window resize step, and as part of that we paint the titlebar+tabbar gradient, which is one big -moz-appearance:-moz-window-titlebar.

The memcpy is not the only cost here; allocating and zeroing out the temporary CGContext is costly, too. And the DrawSurface call is not even a memcpy because it's using operator over and not operator source.
https://hg.mozilla.org/mozilla-central/rev/f90c68af9d88
https://hg.mozilla.org/mozilla-central/rev/7e5eab057928
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla28
(In reply to Markus Stange [:mstange] from comment #11)
> If our current DrawTarget is a Skia software DrawTarget, we should be able
> to rewrap the backing data in a short-lived CGContext.

This patch explores that idea. The hard part is moving over the current clipping region from the DrawTarget to the temporary CGContext. I've reduced the problem to the case when the current clip is a single, pixel-aligned rectangle, and I've only implemented it for DrawTargetCG. The same would need to be done for DrawTargetSkia.
Is this a path worth pursuing?
Attachment #8339920 - Flags: feedback?
Attachment #8339920 - Flags: feedback?(matt.woodrow)
Attachment #8339920 - Flags: feedback?(gal)
Attachment #8339920 - Flags: feedback?
In my tests with the browser UI and simple web pages, the single int rect clip case was always hit.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Whiteboard: [leave open]
Status: REOPENED → ASSIGNED
Comment on attachment 8339920 [details] [diff] [review]
Part 4b [wip]: Wrap existing DrawTarget data for native theme drawing

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

Love the idea!

gfxContext already keeps a stack of clips that have been applied to the DrawTarget, so we could use that rather than implementing tracking inside DrawTargetCG. Even once gfxContext goes away, we will still need shared code somewhere that does this, so it should be safe to rely on.

It would also be nice if we could intersect the rect we're about to draw with the clip, and then see if that's a single rect. That might be better as a TODO, especially since it doesn't seem to be hit very often from your tests.
Attachment #8339920 - Flags: feedback?(matt.woodrow) → feedback+
Talos comparison tables are here: http://compare-talos.mattn.ca/?oldRevs=f71d1d0f7f06&newRev=de12695e172d&server=graphs.mozilla.org&submit=true

So no regression on TART, 3.5% regression on tresize, and 4.5% regression on tscrollx. The latter is probably due to scrollbar painting.
I have a patch to fix the tresize regression and I bet I can actually make us faster than today. I haven't looked into tscrollx yet.
Pushed to try a patch that tells gfxQuartzNativeDrawing that we expect to draw a horizontal or vertical pattern, which we then draw to a thin strip and fill the draw target with FillRect. This should actually be more performant than what we do today.

https://tbpl.mozilla.org/?tree=Try&rev=9d1fcd108061
Note: we can actually cache the pattern surface to make this even faster if needed.
Attachment #8340574 - Attachment is patch: true
Attachment #8340574 - Attachment mime type: text/x-patch → text/plain
Attachment #8340574 - Flags: review?(mstange)
Comment on attachment 8340574 [details] [diff] [review]
Part 4c: Accelerate drawing native widgets that are horizontal or vertical patterns.

This might lose some of the noise effect so maybe not a good idea.
Attachment #8340574 - Flags: review?(mstange)
Attachment #8339920 - Flags: feedback?(gal)
Depends on: 1141917
Blocks: 1239172
Assignee: gal → mchang
Blocks: 1258751
Duplicate of this bug: 1239172
Whiteboard: [leave open] → [leave open][tpi:?]
Depends on: 1274720
Priority: -- → P1
Whiteboard: [leave open][tpi:?] → [leave open][tpi:+]
At [1], we create a new DrawTargetCG just to get a CGContext ref, then snapshot what DrawTargetCG drew and draw the surface onto the destination draw target. We can get a CGContextRef from DrawTargetSkia, so let's do that instead. This is the last known instance of creating a DrawTargetCG (at least locally). 

[1] https://dxr.mozilla.org/mozilla-central/source/gfx/thebes/gfxQuartzNativeDrawing.cpp?q=gfxQuartzNativeDrawing.cpp&redirect_type=direct#42
Attachment #8766398 - Flags: review?(mstange)
Comment on attachment 8766398 [details] [diff] [review]
Borrow a CGContext from DrawTargetSkia to draw native cocoa widget.

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

::: gfx/thebes/gfxQuartzNativeDrawing.cpp
@@ +38,5 @@
>      }
>  
> +    // This actualy just creates an empty DrawTarget to return a CGContext ref.
> +    // We draw the native widget as needed with skia, then draw the resulting
> +    // surface back onto the destination DrawTarget.

Typo in "actualy", and we don't draw widgets with skia. We draw them into the Skia DrawTarget's data, but not using skia.

How about this:

    // Create an intermediate surface as a Skia DrawTarget. We can borrow a CGContext
    // for the data in a Skia DrawTarget, and have native theme drawing draw into that
    // CGContext. The resulting surface is drawn back onto the destination DrawTarget.
Attachment #8766398 - Flags: review?(mstange) → review+
Carrying r+, updated with review feedback, waiting on Gecko 51 to land as Skia content is in Gecko 48.
Attachment #8766398 - Attachment is obsolete: true
Attachment #8766460 - Flags: review+
Some reftests were failing because the Skia surface format would be A8, but we'd try to wrap an RGBA CGContext around it and we'd fail. In those cases, use a grayscale colorspace and set the bitmap to be alpha only.
Attachment #8766862 - Flags: review?(mstange)
Attachment #8766862 - Attachment description: Use a gray color space for alpha only surfaces → Part 2: Use a gray color space for alpha only surfaces
Comment on attachment 8766862 [details] [diff] [review]
Part 2: Use a gray color space for alpha only surfaces

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

DrawTargetCG::Init uses color space NULL for A8 CGContexts. I hope this doesn't make a difference.
Attachment #8766862 - Flags: review?(mstange) → review+
Attachment #8337552 - Attachment is obsolete: true
Attachment #8337564 - Attachment is obsolete: true
Attachment #8337582 - Attachment is obsolete: true
Attachment #8337853 - Attachment is obsolete: true
Attachment #8338105 - Attachment is obsolete: true
Attachment #8339806 - Attachment is obsolete: true
Attachment #8339920 - Attachment is obsolete: true
Attachment #8340574 - Attachment is obsolete: true
ready to land this?
Flags: needinfo?(mchang)
Priority: P1 → P3
From comment 54, waiting until Gecko 51 to land.
Flags: needinfo?(mchang)
Pushed by mchang@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/68e45bab6003
Draw Cocoa Widget without assuming DrawTargetCG. r=mstange
Status: ASSIGNED → RESOLVED
Closed: 6 years ago3 years ago
Resolution: --- → FIXED
See Also: → 1304152
Target Milestone: mozilla28 → mozilla51
You need to log in before you can comment on or make changes to this bug.