There is (or was) a QuartzDebug option to show which parts of a window are actually transparent; on the standard windows only the corners are transparent, so for most of the window area the system can use the faster opaque calculations. I never filed a bug requesting a way for non-Apple code to do that because I didn't think it would be that generally useful - we make "transparent" windows to reproduce the odd shapes that Windows (the OS) provides for our virtual machines.
----- Original Message ----- From: "Andrea3000" <andrea3...@email.it> To: "Cocoa Dev List" <cocoa-dev@lists.apple.com> Sent: Sunday, November 4, 2012 4:52:12 AM Subject: Re: Extremely low fps during transparent NSWindow resize > On Nov 4, 2012, at 4:52 AM, Andrea3000 wrote: > >>> 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. >> >> Thank you for the answer. >> I have just tested it with both Instruments and OpenGL Driver Monitor and it >> seems that the "CPU wait for GPU" time is equal between the two version. >> >>> 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. >> >> Disabling beam synchronization unfortunately does not affect the behavior, >> fps are quite the same. In fact I see no changes when I set >> CGDisableCoalescedUpdates to true. > > Bummer. It seems my hypothesis was disproven. > > >> I'll try this CALayer approach and see if it will improve the performance. >> I'm not experienced with CALayer therefore there is something I'm not >> getting. >> With a regular NSWindow without layers, even if I override the content view, >> I still need to set the window transparent in order to have rounded corners. >> Is it different with CALayer? > > It's the same. > > I just did some testing here and the CALayer approach doesn't seem to work > any better. > > I also tested something else. I set the window to have a bottom border. In > IB, it draws a textured strip along the bottom. It also has slightly rounded > corners, matching the top corners of the title bar. The content view can > overdraw the bottom strip. It appears it can actually draw out of the > rounded corners, but you can take care not to do that. In my testing, the > resizing was fast. > > Unfortunately, I expect that may not work with a borderless window. It also > restricts you to the corner radius that the OS uses in its theme (which also > varies with OS version as Apple tweaks the theme). But it may explain how > QuickTime Player achieves the fast resizing. Exactly, I also tried to set up a bottom border in the past and I've experienced the same behavior. I can confirm that this doesn't work with a borderless window because you can't set the bottom border. Therefore I'm still stuck. Quick Time Player X has a borderless window (or something similar at least) but is still fast as the regular window with bottom border. So the question is: which kind of methods do quick time player x and the "bottom border" window call to draw so fast even if they are (partially?) transparent? I can live with the restrictions of corner radius set by OS until the resize is fast. _______________________________________________ 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/lrucker%40vmware.com This email sent to lruc...@vmware.com _______________________________________________ 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
