1.13 Mouse hover freeze, Repaint patchy

[snmememe]

BitComet 1.13 ADSL2 Billion 7404VNPX UPnP WinXP AVGFree

If I leave the mouse over the View_TorrentList vertical scrollbar, none of the information displayed changes and all traffic is suspended.

Also, depending on the number of pixels allocated for that window vertically, when a page scroll up or down operation is performed using that scrollbar, repainting is unreliable.

[snmememe]

Issues continue same in 1.14.

Strangely, I have come to utilise placing the mouse over that View_Torrent vertical scrollbar as a pause function, though it remains a hazard when I actually want to use the scroll bar as a scroll bar.

I was wondering whether my description of patchy repainting required elaboration. In revisiting this, I found that perhaps the unreliable painting was dependent on having more columns selected than would fit in the horizonal space, and thus a horizontal scroll bar was also active.

Here is a sample, after using scrollbar page down:

[snmememe]

Does lack of response from others imply that my observations haven't been reproduced for others?

On this subject, I have also observed that when the mouse is over that View_TorrentList window there is a huge burst of repeated messages like WM_NCHITTEST, despite no mouse movement, as if BitComet is spending all it's energy on such messages and can't progress any real work.

There also appears to be quite a large amount of message activity at the time of periodic update, even when little or nothing has actually changed, but such isn't necessarily a fault. Similarly lots of periodic messages for the underneath detail list view.

[kluelos]

I'll try again and hope the forum doesn't die on me here.

I was hoping a developer would tackle this, but no, I can't reproduce this problem. I think you recognize, from the flood of mouse messages, that something really strange is going wrong.

That combination of repainting issues and mouse messages, makes me think that it isn't a mouse problem per se, but constant rapid redrawing of the window under the cursor, with the cursor re-registering after each redraw. This does point to a system issue, not a BitComet issue, though.

You can try booting into safe mode w networking and see if the problem goes away. If you can't do that for whatever reason, try deleting your video card from your hardware profile, so it's running as a generic VGA card with no drivers, and see if the issue goes away then. Last, see if you can temporarily borrow a different video card, install that, see if the problem is still there.

[snmememe]

I was hoping a developer would tackle this, but no, I can't reproduce this problem. I think you recognize, from the flood of mouse messages, that something really strange is going wrong.

Let me point out that I see similar symptoms on two entirely different systems.

I don't agree that from the evidence at hand it can be believed to be a problem of these two systems alone.

On one machine at least, if I leave the mouse over that vertical scrollbar the processor usage for BitComet rises from negligable to sit at 75% and all net traffic stops.

On both machines all traffic stops with the mouse over that scroll bar.

I described the spy reports of repeated WM_NCHITTEST as one form of evidence of somthing foul. This is a message used by software to discriminate as to what kind of locality the mouse cursor is at.

[snmememe]

You can try booting into safe mode w networking and see if the problem goes away.

In line with being as helpful as possible, I've booted safe.

Now the ProcExplorer report is a tiny bit different; it shows 99% processor time consumed by BitComet when I park the mouse cursor over the torrent view vertical scroll bar, instead of only 75%.

[snmememe]

I can emphasise that the busy symptom when mouse is over the vertical scroll bar does not occur for me if the torrent view columns are chosen so as to occupy less horizontal measure than available in the window, excluding that occluded region under the vertical scroll bar, and thereby the horizontal scrollbar is disabled.

I can see that the horizontal scroll bar is properly enabled once the total column width has increased up to the full window width minus the vertical scroll bar width, but the busy problem occurs only after the total column required width has been increased yet somewhat further.

If the mouse is positioned so as to be over a portion of a column occluded by the vertical scrollbar the process goes busy.

I've been able to observe faulty repainting upon repeated vertical scroll bar page up or down (i.e. clicking in the scrollbar above or below the thumb), even when the columns are chosen so that the cumulative width is much smaller than the available horizontal measure and no horizontal scrollbar is present.

[greywizard]

I use WinXp and version v.1.14. I've tried to reproduce the behavior you mention but I had no success whatsoever. In fact I seem to be unable to extend the columns beyond the active window. When I try to do that I can see the horizontal bar for a split second and then the columns automatically shrink themselves to fit into the window. How exactly do you do get the horizontal bar in v.1.14? Besides, in my BitComet I don't get those symptoms when clicking above or beneath the scroll bar.

So, I don't know, are there any similarities in hardware and/or software between the systems you tested this on, that might cause this erratic behavior. Because I guess, this is not a "general" bug of this version.

[kluelos]

In line with being as helpful as possible, I've booted safe.

Now the ProcExplorer report is a tiny bit different; it shows 99% processor time consumed by BitComet when I park the mouse cursor over the torrent view vertical scroll bar, instead of only 75%.

That isn't actually helpful. In safe mode you have significantly fewer processes running. If there's something else to do, cpu cycles get distributed over the requesting tasks. (It does that other thing.)

If there isn't anything else to do, cpu cycles go to the task that asks for them until it gets enough, in which case the processor just idles. If there's hardly anybody but BitComet asking, then it doesn't really mean much by itself that BitComet's share increases, or even that it's sopping up close to 100% of the cpu.

What would be important is, if in safe mode, you no longer see the repainting problems, mouse messages, etc. You didn't specify whether that was the case or not.

Unfortunately, that was the heart of the problem and the reason for running the test.

[snmememe]

I use WinXp and version v.1.14. I've tried to reproduce the behavior you mention but I had no success whatsoever. In fact I seem to be unable to extend the columns beyond the active window. When I try to do that I can see the horizontal bar for a split second and then the columns automatically shrink themselves to fit into the window. How exactly do you do get the horizontal bar in v.1.14? Besides, in my BitComet I don't get those symptoms when clicking above or beneath the scroll bar.

So, I don't know, are there any similarities in hardware and/or software between the systems you tested this on, that might cause this erratic behavior. Because I guess, this is not a "general" bug of this version.

I have not had any difficulity using the mouse to drag widen a column so as to cause the horizontal scrollbar to appear.

Now I've tried yet another quite different machine being a recently built Win 7 RTM. The busy symptom didn't show right away until further experimentation produced CPU busy 25%, which is like one of the four cores saturated.

Perhaps the main common similarity among all the machines is me and my choice of columns!

At least one way that I could make the busy symptom appear was to resize column widths so as to make the column that is being occluded by the vertical scroll bar to be in particular "Status", also with BitComet being the foreground active process, and mouse being over part of the status column occluded by the vertical scrollbar.

I looked back to see that the graphic posted some time ago indeed has the Status column occluded by the vertical scroll bar.

Regarding the issue of cell painting subsequent to a vertical scroll bar mouse click page up/down operation, I've found that the behaviour is certainly sensitive to the vertical size of that window. I presume that it matters what kind of remainder results from dividing the window height by the cell height. Perhaps it also matters whether a paint message invalid region becomes lost with the huge amount of message activity, including WM_NCHITTEST, hitting that window proc.

Try making small adjustments to the torrent list window height and then reattempt vertical scroll bar repeated page up/down operations.

[snmememe]

That isn't actually helpful.

...

What would be important is, if in safe mode, you no longer see the repainting problems, mouse messages, etc. You didn't specify whether that was the case or not.

Sorry, I misunderstood your drift. There are two distinguishable symptoms that I have described in this thread.

Evidently you were more focused on painting for that experiment.

From memory the painting was still off when booted safe, but it's not convenient to check such again until a few hours time.

The mispainting is evident on two very different hardware WinXP systems.

Curiously, in a brief experiment on the above mentioned Win7 system I didn't see painting problems, so far at least. That makes me wonder if it is hard to observe on a multi-core machine.

[sophia0316]

snmememe, is it possible that your computer run slowly? So when you use scroll bar, it will take more time to recover? I am sorry, i just guess. Our team wasn't and still isn't able to reproduce your problem.But the team leader know this problem now and if there is some progress, I will let you know.

P.s, sorry that we did not reply you timely.

[snmememe]

What would be important is, if in safe mode, you no longer see the repainting problems, mouse messages, etc.

Confirmed that in Safe mode on two WinXP SP3 uniprocessor systems, a painting problem was observed when using the torrent view vertical scrollbar page up/down.

The cummulative column width didn't seem to matter.

Typically the cell border lines look as if misplaced.

I have already reported seeing that in safe mode the process can go full busy utilisation, at least when mouse is over the status column occluded by the vertical scroll bar.

snmememe, is it possible that your computer run slowly? So when you use scroll bar, it will take more time to recover?

The machines are 2000MHz class AMD of different types, plenty of memory, different video adapters, and not particulary busy doing anything else.

[snmememe]

Further observation related to process full busy when mouse over torrent view vertical scroll bar:

I have already mentioned that I have had the Status column enabled, without which I might not have experienced the herein described process busy condition. Now I ask, what is special about that column?

Without access to the sources I can not be entirely definite, but next consider if any other column can cause trouble. A little experimentaion shows that also the "Down Rate" and "Seed/Peer [all]" demonstrate similar behaviour.

I further note that each of these columns can trigger mouse over tips.

More than that, among the rows of such a column, not all cells will trigger a tip popup, and is only the occasions of the mouse being over a cell that is a candidate to trigger a tip popup that I have observed the the process going full busy when the vertical scrollbar is occluding.

Thus I speculate that the busy problem of this thread is related to orchestration of such tip popups.

I further note that when certain window resizing events occur the column widths tend to be resized to fill the horizontal measure unfortunately including the width of the vertical scrollbar. Note that this will tend to place the ultimate column so that is occluded by the vertical scrollbar and thus in jeaopardy of the busy symptom occurring if it happens to be a column that spawns mouse over tip popups.

This is like begging for trouble, and why the problem has been so persistent for me. Even if I had sized the ultimate Status column to not be occluded, the next auto resize would make it occluded and thus invoke the full busy symptom whenever the mouse was over that vertical scrollbar.

Is this speculation on course, or is there still no one else in the world that has experienced such a process full busy condition? Am I so lonely?

[sophia0316]

Am I so lonely?

I am afraid now, you are the only one have this problem.

Gavin tested many times, but still can not reproduce it. :(