Re: Extremely low fps during transparent NSWindow resize
Re: Extremely low fps during transparent NSWindow resize
- Subject: Re: Extremely low fps during transparent NSWindow resize
- From: Ken Thomases <email@hidden>
- Date: Sat, 03 Nov 2012 20:27:43 -0500
On Nov 1, 2012, at 6:48 AM, Andrea3000 wrote:
> I'm trying to address a performance problem regarding transparent NSWindows during resize.
> This way I have a borderless NSWindow which is transparent with a NSView that draws an opaque NSRect with rounded corners.
> Therefore it gives me a NSWindow which appears opaque but with rounded corners.
> The problem, though, is that when the window has a size above (let's say) 1280x800 pixels and I start to perform a resize, the resize animation becomes sluggish with an overall refresh rate which is below 20fps (as measured by Quartz Debug).
> If I comment out the line "[self setOpaque:NO]", the window is no more transparent and therefore I lose the rounded corners but the resize animation is again smooth with a refresh rate always above 45 fps.
>
> I have then sampled the app with Time Profiler with both transparent and opaque NSWindows.
> To do that I have recorded (with UI Recorder) a 30 seconds resize in which I have exploited both slow and fast resizes, and I have applied this record to the two versions of the app.
>
> What I've found is that the CPU time required by every functions is equal in percentage between the transparent and the opaque NSWindow (i.e.: aa_render from CoreGraphics takes around 31% of the total CPU time with both transparent and opaque NSWindow, CGSColorMaskCopyARGB8888 from CoreGraphics takes around 22.0%, etc..)
>
> The strage fact is that the total CPU time of the opaque window version is more than TWICE of that of the transparent window version...and this seems to be a nonsense since the opaque version is much faster and more smooth than the transparent version.
This suggests that the limiting factor is the GPU and/or the window server's throttling of the refresh rate. So, the process isn't using much CPU time because it's blocked waiting for the GPU or window server to recomposite the window into the screen image.
If you take a time profile and enable "All Thread States" in the instrument configuration, it will show the time your process spends waiting on the GPU or window server and there should definitely be a difference between the transparent and opaque window scenarios.
> This led me to think that the problem could be that in the case of transparent NSWindow the -drawRect method gets called with a rate which is less than half of that of the opaque window and this may also explain why the fps of the transparent version are less than half of those measured with the opaque version.
> To verify this I have counted the number of -drawRect calls and my hypothesis holds true; in the opaque version that method gets called more than twice as frequently than the transparent version.
Yup, consistent with my hypothesis.
> How is it possible to obtain the same refresh rate as with the opaque window?
You might try the techniques outlined in this technote:
https://developer.apple.com/library/mac/#technotes/tn2133/
In particular, try disabling beam synchronization in Quartz Debug to see if that affects the behavior. If it does, you can try adding the key CGDisableCoalescedUpdates to your Info.plist, but that should be considered a last resort.
Maybe a better approach would be to use Core Animation layers. Those can have rounded corners and that may allow the system to update them in a better manner.
Regards,
Ken
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden