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