Charts blocks drawing while '2 Threads' is selected [...]

[johndrinkwater]

run Chart, set it up so you can see a moving animation, select '2 Threads' option. Window doesn't continue its updates, app still remains responsive though. Unselecting '2 Threads' returns Charts to normality.

[jackburton]

Can't reproduce this anymore. Maybe it's been fixed in the meantime ?

[johndrinkwater]

I still see this on rev16097 in vmware with 32bit mode, using either directwindow+drawbitmap

[jackburton]

Weird, I can reproduce it, but not consistently. Maybe it's timing related ?

[johndrinkwater]

On the first attempt to select "2 threads", it'll take a random duration to block drawing.

Any further attempts (re-enabling 2 threads) stops drawing directly after selection. Sounds deadlocky(?) on the second thread.

[stippi]

Can you guys reproduce this on R5?

[jackburton]

Chart also hangs on quit. Could be related, as uncommenting the line

"wait_for_thread(fSecondAnimationThread, &result);"

in ChartWindow.cpp (ChartWindow::~ChartWindow()) makes the app quit correctly.

I'd be interested in seeing how the app behaves in BeOS and in the testing environment. Unfortunately, I can't test on either.

[johndrinkwater]

I've been playing with this on native hardware, and cant reproduce. With testing the same revision in vmware, I can reproduce.

Maybe a gfx/vmware problem ? Is there any debug output that could help here?

[jackburton]

Replying to johndrinkwater:

The weirdest thing is that I tried to add some debug output, and then the problem doesn't show up anymore.

[jackburton]

I don't know why but I can't reproduce it anymore. I'll close this bug if no one complains.

[aldeck]

Replying to jackburton:

I can confirm that the bug appears under vmware with either haiku or hrev5. No problem on real hardware.

Hardcoding all instances of fSecondThreadThreshold to 0.5 in ChartWindow.cpp seems to solve the 2 threads problem. The code must be blocking itself with erroneous timing calculations. This old code is a bit too geeky/complicated for what it does IMHO :) Don't know if it's due to my modification but on one time it didn't quit properly (window closing only).

What lead me to this is the strange cpu usage display, especially when animation is off but drawing is enabled. It's maybe unrelated but i thought some timing calculation might be responsible. Maybe a clock/cpu usage issue under vmware? Or Charts is the only suspect :)

[jackburton]

Finally fixed in hrev22961. The calculations to distribute the load between the two threads don't seem to work correctly under vmware: they set the load for one thread to a negative number.

[nielx]

Per request of katisu.

[jackburton]

Is it reproducible in the way described in the description ? Does this happen on a SMP machine ? I cant' reproduce it here, either on vmware or real hardware (although the bug only seemed to apply on vmware).

[aldeck]

Replying to nielx:

Per request of katisu.

Any more info? Niels, what did katisu report?

[nielx]

Don't know. It was reported on the mailing list that reopening this ticket caused problems. I assumed that there was an actual reason to reopen the ticket. Cc changed to ask for more input.

[nielx]

Changing the summary to see if that makes any difference.

[nielx]

Hi Niels,

I still can't post a comment due to that "Ticket needs summary" error. Here is the info, please post it.

-- Problem still exists as reported to me by Anxiety on irc (using hrev23938). I was able to verify/reproduce problem using hrev23938 and have done so as recently as hrev24049 running under vmware player. Can't reproduce on native hardware (366 Celeron).

Set the animation running and select 2 threads and after a duration of time (time amount isn't consistent) the animation is frozen. After this, deselecting 2 threads restarts it, reselecting 2 threads freezes it again. I did this on a P4 HT 3GHz. First I had an old version of vmware player, but still reproducible even in the newest version of 2.02. --

Curtis (aka Katisu)

[aldeck]

Replying to nielx: Hmm, working on something else at the moment but we might need to write a test app for time functions and see if strange things happen under vmware...

[jackburton]

Replying to aldeck:

Replying to nielx: Hmm, working on something else at the moment but we might need to write a test app for time functions and see if strange things happen under vmware...

I agree. BTW I could reproduce this bug again, if I let the app run for a relative long time with "2 threads" enabled.

[richienyhus]

Is this still valid ?

[humdinger]

I just installed VirtualBox and tried hrev39180. The ticket is still valid. Checking "2 threads" will stop the drawing, cpu usage goes back to idle(?). Unchecking "2 threads" starts the drawing again. There's no delay for me. This is on a Core2Duo, though VB refuses to start with more than one CPU, so there's only one core according to Pulse.

In general, Haiku uses an awful lot of CPU when just moving the mouse in VB... Thank gods my virtual times are over! :)

[diver]

Still here in hrev44622.

[pulkomandy]

I can't reproduce this on rela hardware. Is it still a problem?

[diver]

Yes, drawing still blocks in hrev48022.

[jackburton]

I'd lower the priority, though, since it only happens on certain configurations, and it's not exactly a critical component.

[stpere]

I put a workaround in hrev49353. Basically, you could have a situation like this : bigtime_t before = system_time(); SomeCalculation(); SomeOtherCalculation(); bigtime_t after = system_time();

and you could have some cases where after - before < 1 (either 0 or negative). When used in the division right after, you would have a division by 0 (NaN) that would break the logic further down and poison the animation as the ratio is calculated from the ratio calculated in the previous cycle.. NaN * NaN, etc..

So, I made sure the after-before was at least 1 and it seems to work ok. Since the time calculation was more or less only there to calculate a load ratio, it doesn't have to be extra accurate.