1. TortoiseHg
  2. TortoiseHg
  3. hgtk
  4. Issues
Issue #101 resolved

Repainting the lower right pane of commit window takes 5-10 secs & 100%CPU

Anonymous created an issue

Any repainting of the part of the commit window that shows the diff for the selected file be it window resize or scrolling or another window minimised and uncovering portions of its area will cause hgproc.exe to use 100% cpu for 5-10 secs and the window is unresponsive during this time. Any other part of the commit window can be redrawn without problems. Even moving the mouse around inside this area is causing lots of cpu but it is not causing any rendering glitches just with moving the mouse.

Using winxp sp3, intel GMA mobile graphics on thinkpad T61. version 0.6 was working fine, this started with v0.7

Comments (9)

  1. Anonymous

    I tried nightly 090314 and the problem is still there on this system.

    Tried a different system and 0.7 is working OK. GTK problem with this graphics driver maybe then? Are there any GTK settings I can tweak?

  2. Steve Borho

    very few. You can look try one of the other themes, or looking at their gtkrc files, but I'm guessing that nothing configurable there would make a dent in this problem. Thanks for the update.

  3. Anonymous

    The first time I noticed this I uninstalled and reinstaleld choosing a different theme and it was still there with both the vista reccommended theme and the standard windows one. Cant remember names but the top and bottom ones from the installer, so no joy there.

  4. Steve Borho

    Maybe you should get in with that class-action lawsuit against Intel and their 'so called' GPUs. :)

    Wish I had a solution, but I suspect there's nothing I can do outside of dropping GTK.

  5. Doug Philips

    Do I understand that 0.7's GTK is fine, but 0.7.1, er, nightly builds, is not? Sounds like "upgrading" GTK post 0.7 was the problem? And that they need a bug report for performance degradation? Just wondering what's really going on here...

  6. Steve Borho

    I think the initial bug reported here is another way for the TreeView buffer overflow to present itself, and the later bugs reported here are definitely related to the crash reported in #182 and now fixed on stable. So I'm going to mark this as resolved. Please reopen if the performance issue is not fixed by 0.7.5.

    The GTK+ developers have reproduced the bad behavior on win32 in a much simpler test case, so there's a good chance it can be fixed in a later release and I can ease up on the 128 char limit.

  7. Log in to comment