942688 - Draw Cocoa Widget without assuming DrawTargetCG

Status: RESOLVED FIXED

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

Description

[Andreas Gal :gal]

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.

Comment 1

[Andreas Gal :gal]

Attachment: Part 1: Draw title bar decoration with CG directly.

Comment 2

[Andreas Gal :gal]

Attachment: Part 2: Draw corner mask with Azure.

Comment 3

[Andreas Gal :gal]

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);

Comment 4

[Andreas Gal :gal]

Attachment: Part 3: Remove code to draw resizers.

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.

Comment 5

[Andreas Gal :gal]

Attachment: Part 4: Native drawing with CGContext borrowing.

Comment 6

[Andreas Gal :gal]

Attachment: Part 5: Remove CGContext borrowing.

With this we should be able to use skia to render the UI on cocoa.

Comment 7

[Markus Stange [:mstange]]

I can do the reviews here if you'd like me to. I think Jeff is still on vacation.

Comment 8

[Andreas Gal :gal]

Attachment: Part 6: Render cocoa UI with skia.

Comment 9

[Markus Stange [:mstange]]

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.

Comment 10

[Markus Stange [:mstange]]

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 11

[Markus Stange [:mstange]]

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.

Comment 12

[Andreas Gal :gal]

Attachment: rollup patch for mstange

Comment 13

[Andreas Gal :gal]

Attachment: Part 1: Draw title bar decoration with CG directly.

Comment 14

[Andreas Gal :gal]

https://tbpl.mozilla.org/?tree=Try&rev=e16b446f2df5

Comment 15

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

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.

Comment 16

[Andreas Gal :gal]

Attachment: Part 7: Always render rounded rects.

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).

Comment 17

[Andreas Gal :gal]

Attachment: Part 8: Always enable OMTC.

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.

Comment 18

[Markus Stange [:mstange]]

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).

Comment 19

[Markus Stange [:mstange]]

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 20

[Markus Stange [:mstange]]

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 21

[Markus Stange [:mstange]]

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.

Comment 22

[Markus Stange [:mstange]]

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.

Comment 23

[Andreas Gal :gal]

Yeah totally agree that 7- should be fixed separately.

Comment 24

[Andreas Gal :gal]

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

Comment 25

[Andreas Gal :gal]

just part 1: https://tbpl.mozilla.org/?tree=Try&rev=dbd4d814940a

Comment 26

[Andreas Gal :gal]

part 1+2: https://tbpl.mozilla.org/?tree=Try&rev=c5e3807ce63b

Comment 27

[Andreas Gal :gal]

part 1+2+3: https://tbpl.mozilla.org/?tree=Try&rev=2d1db7b6e8a6

Comment 28

[Andreas Gal :gal]

I can confirm a problem with part 4 locally.

Comment 29

[Andreas Gal :gal]

Man the try server build times are really ridiculous these days.

Comment 30

[Andreas Gal :gal]

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.

Comment 31

[Andreas Gal :gal]

(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?

Comment 32

[Andreas Gal :gal]

Part 3 actually passes too but mstange had concerns about the scroll bar.

Comment 33

[Andreas Gal :gal]

Never mind found it.

/layout/generic/nsGfxScrollFrame.cpp (View Hg log or Hg annotations)
line 3854 -- if (!widget || !widget->ShowsResizeIndicator(&widgetRect))

Comment 34

[Andreas Gal :gal]

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.

Comment 35

[Andreas Gal :gal]

Attachment: Part 4: Native drawing with CGContext borrowing.

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);

Comment 36

[Andreas Gal :gal]

Need a follow-up to use moz2d to composite the CG bitmap, asserting that we always have a draw target.

Comment 37

[Andreas Gal :gal]

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.

Comment 38

[Andreas Gal :gal]

Attachment: Part 4: Native drawing without CGContext borrowing.

Comment 39

[Markus Stange [: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.

Comment 40

[Markus Stange [:mstange]]

(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.

Comment 41

[Carsten Book [:Tomcat]]

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

Comment 42

[Markus Stange [:mstange]]

Attachment: Part 4b [wip]: Wrap existing DrawTarget data for native theme drawing

(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?

Comment 43

[Markus Stange [:mstange]]

In my tests with the browser UI and simple web pages, the single int rect clip case was always hit.

Comment 44

[Matt Woodrow (:mattwoodrow)]

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.

Comment 45

[Andreas Gal :gal]

Talos push with the patch:

https://tbpl.mozilla.org/?tree=Try&rev=de12695e172d

Talos push without the patch:

https://tbpl.mozilla.org/?tree=Try&rev=f71d1d0f7f06

Comment 46

[Markus Stange [:mstange]]

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.

Comment 47

[Andreas Gal :gal]

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.

Comment 48

[Andreas Gal :gal]

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

Comment 49

[Andreas Gal :gal]

Attachment: Part 4c: Accelerate drawing native widgets that are horizontal or vertical patterns.

Note: we can actually cache the pattern surface to make this even faster if needed.

Comment 50

[Andreas Gal :gal]

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.

Comment 52

[Mason Chang [Inactive] [:mchang]]

Attachment: Borrow a CGContext from DrawTargetSkia to draw native cocoa widget.

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

Comment 53

[Markus Stange [: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.

Comment 54

[Mason Chang [Inactive] [:mchang]]

Attachment: Borrow a CGContext from DrawTargetSkia to draw native cocoa widget.

Carrying r+, updated with review feedback, waiting on Gecko 51 to land as Skia content is in Gecko 48.

Comment 55

[Mason Chang [Inactive] [:mchang]]

Attachment: Part 2: Use a gray color space for alpha only surfaces

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.

Comment 56

[Markus Stange [:mstange]]

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.

Comment 57

[Jim Mathies [:jimm]]

ready to land this?

Comment 58

[Mason Chang [Inactive] [:mchang]]

From comment 54, waiting until Gecko 51 to land.

Comment 59

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/68e45bab6003
Draw Cocoa Widget without assuming DrawTargetCG. r=mstange

Comment 60

[Mason Chang [Inactive] [:mchang]]

Try looked good - https://treeherder.mozilla.org/#/jobs?repo=try&revision=b72b483979eb

Comment 61

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/68e45bab6003