> On 4 Jul 2017, at 6:02 pm, Graham Cox <graham....@bigpond.com> wrote:
>
> I can live with layer-backing as a solution, it doesn’t appear to have any
> downsides.
I spoke too soon.
Layer backing disguises the performance issue by capturing the first render
pass which is then used for scrolling. So scrolling is fast.
But the render pass itself is still really slow. It’s not quite as bad, because
it only does it once for each new reload of the table view, rather than on
every scroll change. But it’s still spending an excruciating amount of time
rendering the title of the pop-up button, but most of it is in the mysterious
rgba64_DAplusdDA function. This is called twice for each pop-up button
rendered, and the time divides fairly evenly between them.
It’s a bit hard to post the full stack trace as it’s so deep, but here are the
two main branches, with much in between them collapsed (every line is meant to
be indented from the one above, but mail isn’t preserving the formatting at
all).
24.72 s 78.7% 0 s -[NSTableView
drawRect:]
24.55 s 78.1% 0 s -[NSTableView
drawRowIndexes:clipRect:]
24.54 s 78.1% 1.00 ms -[NSTableView
drawRow:clipRect:]
24.16 s 76.9% 0 s -[NSTableView
_drawContentsAtRow:column:withCellFrame:]
22.30 s 70.9% 0 s
-[NSPopUpButtonCell drawWithFrame:inView:]
10.63 s 33.8% 0 s
-[NSMenuItemCell drawWithFrame:inView:]
10.45 s 33.2% 1.00 ms
-[NSMenuItemCell drawInteriorWithFrame:inView:]
10.44 s 33.2% 0 s
-[NSMenuItemCell drawTitleWithFrame:inView:]
10.44 s 33.2% 1.00 ms
-[NSButtonCell _configureAndDrawTitleWithRect:cellFrame:controlView:]
10.36 s 32.9% 0 s
drawTitle_withFrame_inView_
10.36 s 32.9% 1.00 ms
-[NSPopUpButtonCell drawTitle:withFrame:inView:]
10.29 s 32.7% 0 s
_NSStringDrawingCore
10.29 s 32.7% 2.00 ms
__NSStringDrawingEngine
10.20 s 32.4% 1.00 ms
-[NSLineFragmentRenderingContext drawAtPoint:inContext:]
10.19 s 32.4% 1.00 ms
-[CUICatalog
drawGlyphs:atPositions:inContext:withFont:count:stylePresetName:styleConfiguration:foregroundColor:]
10.16 s 32.3% 1.00 ms
-[CUITextEffectStack
drawGlyphs:inContext:usingFont:atPositions:count:lineHeight:inBounds:atScale:]
9.71 s 30.9% 0 s
CGContextEndTransparencyLayer
9.71 s 30.9% 0 s
ripc_EndLayer
9.70 s 30.8% 0 s
ripc_RenderImage
9.70 s 30.8% 0 s
RIPLayerBltImage
9.70 s 30.8% 0 s
ripl_Mark
9.70 s 30.8% 1.00 ms
rgba64_image
9.61 s 30.5% 2.15 s
rgba64_mark
7.46 s 23.7% 7.46 s
rgba64_DAplusdDA
24.72 s 78.7% 0 s -[NSTableView
drawRect:]
24.55 s 78.1% 0 s -[NSTableView
drawRowIndexes:clipRect:]
24.54 s 78.1% 1.00 ms -[NSTableView
drawRow:clipRect:]
24.16 s 76.9% 0 s -[NSTableView
_drawContentsAtRow:column:withCellFrame:]
22.30 s 70.9% 0 s
-[NSPopUpButtonCell drawWithFrame:inView:]
10.63 s 33.8% 0 s
-[NSMenuItemCell drawWithFrame:inView:]
10.38 s 33.0% 0 s -[NSCell
_endVibrantBlendGroup]
10.38 s 33.0% 0 s
CGContextEndTransparencyLayer
10.38 s 33.0% 0 s
ripc_EndLayer
9.66 s 30.7% 0 s
ripc_RenderImage
9.66 s 30.7% 1.00 ms
RIPLayerBltImage
9.66 s 30.7% 0 s ripl_Mark
9.66 s 30.7% 0 s
rgba64_image
9.58 s 30.4% 2.07 s
rgba64_mark
7.51 s 23.8% 7.51 s
rgba64_DAplusdDA
What seems weird to me is that the time used to render the string itself is not
a problem - it’s the blitting of the resulting captured CGLayer afterwards that
seems to kill it. But that doesn’t seem to be happening for any other content
in the table view - just the pop-up button’s title. All the other strings I’m
drawing don’t figure here at all (and there are two of those for every pop-up).
I’m going to see if I can put together a minimal test case that shows the same
issue - it’s really looking like Apple’s bug to me.
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
