GitX Excessive CPU Usage Patch

[David Anderson]

For every project I'd have open in GitX another 10% of my CPU would
get consumed. However, this would only occur when the commit view was
visible, not when the History view was open. After a bit of time in
Shark, I could see that the PBCommitMessageView drawRect: method was
one of the two contributors to CPU usage.

I don't personally understand the reason for the feature, but the
vertical line indicating a 50 column width in the PBCommitMessageView
was causing the entire text view to be redrawn with each cursor blink
(in and out) for the key window. Instead of keeping the subclassed
NSTextView, I placed a subclassed NSView behind the NSTextView, and
then I set the (commit) NSScrollView and NSTextView to not draw their
background. Now when the cursor blinks, only the single line of the
NSTextView is redrawn, and the dirty portion of the subclassed NSView
(PBCommitMessageBackgroundView) is redrawn. The
PBCommitMessageBackgroundView references the commit NSTextView for the
typing attributes, background color, etc.

The other significant contributor to CPU usage was the Commit button
fading in and out continuously. While it looks nice for panels and
alerts, the NSButton with the Return key equivalent is not appropriate
for the Commit window. The NSTextView (formerly PBCommitMessageView)
is first responder and accepts the Return character, thereby masking
the Commit button from receiving the key equivalent. Removing the key
equivalent binding for the Commit button eliminated the remaining CPU
usage.

With these two changes, and three projects open in GitX on the Commit
view, the CPU usage for the active application has gone from ~33% to
~0.3%. When GitX is not the active application, CPU usage drops to
0.0%.

I'm not sure if/how you want to incorporate the .xib changes (as we
appear to be using different versions of the dev tools), but please
find the attached patches for my changes.

[David James]

On my system, I just confirmed:

* in the commit view, gitx consumes roughly 7% CPU

* in the history view, gitx does not consume the CPU

Here's the rationale for the 50 character line:

http://www.tpope.net/node/106

I also wrote a post to this list requesting more nudges about well-formed commit messages:

http://groups.google.com/group/gitx/browse_thread/thread/9740cf9d9e2cc52c/3c5870970daae519

"

I've noticed that gitx currently has a vertical bar to help us 

remember the 50 character mark. Could we also add something similar 
for the 72 character mark? 

It might be worth considering using the approach using with VIM 
integration: 
http://vim.runpaint.org/extending/integrating-vim-with-git/ 

"

Dave

[sk][p]

Thanks for the clarification on the subject/body best practice. I'll
take a look at adding a 72 character line.

As an improvement, should there actually be separate Subject and Body
text fields that, on commit, are combined as a single commit message
with a blank line separating, and where the subject field is limited
to 50 characters and the body field contents wrap at 72 characters?

Yes, the two text fields would forcibly constrain the input to match
the best practice, but two lines don't directly inform the user how
they are to be used. (Originally I thought the line was a drawing
bug, not a feature.)

For VIM (or TextMate) the text coloring is the only available
guideline, but a full GUI allows for a more direct "solution".

Thoughts?

Dave

On Oct 31, 9:18 am, David James <dja...@sunlightfoundation.com> wrote:
> On my system, I just confirmed:
> * in the commit view, gitx consumes roughly 7% CPU
> * in the history view, gitx does not consume the CPU
>
> Here's the rationale for the 50 character line:http://www.tpope.net/node/106
>
> I also wrote a post to this list requesting more nudges about well-formed

> commit messages:http://groups.google.com/group/gitx/browse_thread/thread/9740cf9d9e2c...

>
> "
> I've noticed that gitx currently has a vertical bar to help us
>

> remember the *50 **character* mark. Could we also add something similar
> for the 72 *character* mark?

[sk][p]

I have a patch to add the 72 character line, but it makes me wonder if
the textfield window should be a maximum of 72 characters wide. I
don't seem to be able to add another attachment to this thread, so the
new patch will have to be in a new thread. (boo)

On Nov 2, 9:28 am, "sk][p" <skipandma...@gmail.com> wrote:
> Thanks for the clarification on the subject/body best practice.  I'll
> take a look at adding a 72 character line.
>