Created attachment 260284 [details] [review]
boxpointer: Don't hide when we're already hidden

Created attachment 260285 [details] [review]
boxpointer: Don't hide when we're already hidden

You would think we would already do something like this, but apparently
lots of code was calling hide() without checking if the box pointer was
already visible, causing it to queue a full tween. The biggest win was
with ibusCandidatePopup.js, which called hide() on every DBus message.

This increases the performance for me to enter the overview by a tiny
bit. The remaining time is spent updating the frequent apps / all apps
display.



So, when I went to rebase, I found an uncommitted line in my tree. Whoops.

Review of attachment 260285 [details] [review]:

Yeah. Seems like we should do the same for show()

But we should still run the onComplete callback if one is provided in this case, no? I think that's would be reasonable though, on a quick look, I didn't find any calling code relying on that

(In reply to comment #3)
> Yeah. Seems like we should do the same for show()

I can't imagine that being hit as often. This was mostly the case of a bunch of code repeatedly calling hide() on a boxpointer that was already hidden.

(In reply to comment #4)
> But we should still run the onComplete callback if one is provided in this
> case, no? I think that's would be reasonable though, on a quick look, I didn't
> find any calling code relying on that

I don't know. I feel like some code that runs the onComplete callback only expects it to run when there was an actual transition. The goal here is to do less, so I'd say it's OK to not run it.

Attachment 260285 [details] pushed as d77fc01 - boxpointer: Don't hide when we're already hidden