![]() So, if you would like to create another app using the dockTile api, we can compare and see if that helps any. At least on Nightly, the progress bar is a little hard to see and looks a little out of place being more squared and longer then the icon. And although UI-review has already been given, I have to say I would prefer if possible that we draw *under* the app icon, instead of on it. > It remains a fallback option if there's nothing better we can do, but I'd > Yeah that's the "NSProgress" we discussed in the earlier bug: > Here's a video showing what Safari does. > (In reply to Josiah Bruner from comment #25) (In reply to Dave Vasilevsky from comment #26) Doing something like that could benefit us and is actually better on OS X integration. If you take a look at their icon, they use a thin, solid blue bar that only updates when progress is made. If I could suggest something, I would say we follow Safari's approach. It would appear that the 3D dock with reflection and Gaussian blur dramatically increases CPU. However, you were quite right about Dock position. Thanks Dave! Indeed, Dock's CPU is going up by 30% as seen on Firefox. Look into using the NSProgress private API, maybe with fallback to the See if a custom look (like Chrome's circle thing, or a solid blue bar) See if abandoning phase animation altogether lets us update less often See if we can lower the update rate without making animation choppy. See if using the dockTile API is any better than setApplicationIconImage. > Once we make sure we can reproduce the problem this way, we can look into > thinking the CPU usage might have to do with the special effects applied to > difference whether the Dock is on the side or the bottom of the screen? I'm > Also, just to check a suspicion of mine, can you check if it makes a > build this on 10.8 and report whether or not it shows the same performance > Firefox dock progress drawing code to a test app: > To start with, I want to get a minimal test case working. > Ok, thanks for your patience folks, I have some time to look at this now. (In reply to Dave Vasilevsky from comment #22) Look into using the NSProgress private API, maybe with fallback to the existing code on 10.6. See if a custom look (like Chrome's circle thing, or a solid blue bar) lets us update even less often.ĥ. See if abandoning phase animation altogether lets us update less often without looking ugly.Ĥ. See if we can lower the update rate without making animation choppy.ģ. See if using the dockTile API is any better than setApplicationIconImage.Ģ. Once we make sure we can reproduce the problem this way, we can look into mitigation. I'd appreciate if folks could build this on 10.8 and report whether or not it shows the same performance issue as folks are seeing in Firefox.Īlso, just to check a suspicion of mine, can you check if it makes a difference whether the Dock is on the side or the bottom of the screen? I'm thinking the CPU usage might have to do with the special effects applied to the Dock when it's on the bottom. I've copied the Firefox dock progress drawing code to a test app. To start with, I want to get a minimal test case working. Ok, thanks for your patience folks, I have some time to look at this now.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |