Possible Bug in TTrackbar (win7-x64)?

[feds]

Hi all

I have a strange behavior with TTrackbar and was not able to figure out from where it comes from.
The result is that my win7 is loaded so heavy that it is amost impossible to do anything.

This is so simple to reproduce (at least here) that i will give a short description instead of an example project (hope that's ok).
(But be prepared to restart your pc after the test)

1. Make a new GUI project.
2. Place a TTrackbar on the main form.
3. Create an onCreate handler for the form and add

Code: Pascal  [Select][+][-]

1. procedure TForm1.FormCreate(Sender: TObject);
2. begin
3.   TrackBar1.Max := MaxInt;
4. end;    

4. Run the project

After a few seconds my mouse moves quite slow and i'm not able to enter anything (it looks like even Ctrl-Alt-Del is not processed anymore).

System is Lazarus 2.0 64Bit, SVN 60307 on Win7_64. I was not able to test this under Linux yet.

Can anyone please conform this behavior?
Is this a known bug (i didn't find it in the bug tracker)?

Any hints are realy appreciated.

Kind regards
feds

P.S:
Just in case that someone wonder why i tried to assign MAXINT to the max property:
While trying to become familiar with RTTI-components i accidently linked a trackbar to an integer property of the model. Unfortunally the "UseRTTIMinMax" is set to true by default. This means the trackbar got it's min & max values from the model (an integer).
 

[ASerge]

Can anyone please conform this behavior?
Any hints are realy appreciated.

Confirm. Track bar also drawing ticks. With default TickStyle=tsAuto it's drawing MaxInt ticks. This is a very long process. Set TickStyle=tsManual if you use such a large range of values.
BTW, Delphi checks this and when the range exceeds 10000, it internal sets the control style like TickStyle=tsManual.

[jamie]

I suppose the tick drawing is being done under the OS so it's hard to control..

 You would think that maybe drawing should be pre-scaled and tested for change via the scale before it does out and updates the tick scale.

[winni]

Linux, gtk2, KDE Plasma:

gtk2 answers to the windows bug with a "workaround bug":

The Trackbar does not show ANY ticks. So there is no problem with drawing maxint ticks.
As max position value 2 147 483 647 is shown. Good boy.

Winni

[wp]

I committed a change of TTrackbar which picks up ASerge's post and switches to TickStyle = tsNone when the difference between Max and Min is > $3FFF (r61810)

Backporting to Laz fixes has been requested. If you don't use trunk and can't wait for Laz 2.0.6 you can patch the procedure yourself: Go to folder lcl/include of the Lazarus installation. Open file "trackbar.inc" and find the procedure TCustomTrackbar.FixParams. Add the following lines before the "end;":

Code: Pascal  [Select][+][-]

1.   if AMax - AMin > $3FFF then
2.     SetTickStyle(tsNone);

Of course, it should be mentioned that you should make a backup-copy of the original file.

[winni]

With this fix old workarounds would not work anymore:

Code: Pascal  [Select][+][-]

1. trackbar.Min        := 0;
2. trackbar.Max        := 50000;
3. trackbar.Frequency  := 5000;
4.  

Winni

[wp]

I know. There's something happening with 64-bit which I do not understand: Keeping Style=tsAuto but increasing the interval length such that there are only a few ticks to be drawn, e.g. SetFrequency((AMax - AMin) div 10), keeps the system at an awfully slow speed once the Max becomes sufficiently large. This does not happen on 32-bit (which is fast even without the fix).

[winni]

I can confirm that. Half an hour ago I did this:

Code: Pascal  [Select][+][-]

1.    Screen.Cursor:= crHourGlass;
2.    TrackBar1.Max := MaxInt;
3.    TrackBar1.Frequency:= Maxint div 10;
4.    Screen.Cursor:= crDefault;        
5.    

Went to the kitchen to make fresh coffee. When I came back the hourglass was still rotating. I killed that beast. This time everything on win7/64. I have got no 32 bit no more to test.

Winni

[winni]

Again about the 4 lines of code in my last post.

First my configuration: Win7 prof with 8 GB on VirtualBox on Ryzen  5 2400g

I started them again and looked at the task manager:

First 20 - 25% CPU load, then constant 25% - so that is one of 4 processors under total load.
Memory: First 7.3 GB (!!), later 7.9 GB of 8.192 GB - a little bit left for Lazarus, Virtualbox and Task Manager. The system started swapping and then the CPU .load went up to 50% - the second CPU had it lot to do with swapping.

Now those 4 lines run more than 24 minutes (!!!) and I'm gonna kill them. Whatever just happens inside the machine. Miracles, miracles ....

Winni

[wp]

Maybe I should increase the limit at which the patch becomes active. I noticed only a relatively short delay when the Max is 8 times smaller than MaxInt. Can you confirm this?

Code: Pascal  [Select][+][-]

1. procedure TForm1.FormCreate(Sender: TObject);
2. begin
3.   Trackbar1.Max := MaxInt shr 4;
4.   Caption := Format('%.0n', [1.0*Trackbar1.Max]);
5.   Trackbar1.Frequency := Trackbar1.Max div 100;
6. end;

[jamie]

is it possible there is a flood of notification messages coming in?

Could using the Peekmessage with the Remove flag help after receiving the flooded message?

[winni]

Hi!

With your code the needed RAM goes down to "only" 0.5 GB.

But the CPU load is at 25% and it seems that it is this time not an endless loop:

It took "only" 4 minutes and 12 seconds!!! Feels like old 6502 times!

There must be something real weird going on.

Winni

[feds]

I'm really impressed from your answers and learned a lot. Thanks for this 

I know. There's something happening with 64-bit which I do not understand: Keeping Style=tsAuto but increasing the interval length such that there are only a few ticks to be drawn, e.g. SetFrequency((AMax - AMin) div 10), keeps the system at an awfully slow speed once the Max becomes sufficiently large. This does not happen on 32-bit (which is fast even without the fix).

Half an hour ago I did this:

Code: Pascal  [Select][+][-]

1.    TrackBar1.Frequency:= Maxint div 10;
2.    

As far as i understand what happens: Setting Frequency results in a TBM_SETTICFREQ message, putting the fFrequency in the WParam. But WParam is only 16bit. Hence (i assume) the frequency used by Win32 is massivly smaller than expected.

Only for testing i tried a similar (but horrible) approach with

Code: Pascal  [Select][+][-]

1. procedure TCustomTrackBar.FixParams(var APosition, AMin, AMax: Integer);
2. var
3.   tickRange : integer;
4. begin
5.  
6.   if AMin > AMax then AMin := AMax;
7.   if APosition < AMin then APosition := AMin;
8.   if APosition > AMax then APosition := AMax;
9.  
10.   tickRange := AMax - AMin;
11.   if tickRange div fFrequency > Width then
12.     Frequency := tickRange div Width;
13.  
14. end;  
15.  

and got the same result. Althrough Frequency was set as expected, the Frequency is much larger than the 16bit range. Hence the result is still terrible slow 

Regards
Feds

Update:
My fault. WParam was extended to 32bit years ago.  Long time ago when i was hacking Win32 stuff :/
F.

[wp]

Code: Pascal  [Select][+][-]

1. var  
2.   tickRange : integer;
3. begin
4. ...
5.   tickRange := AMax - AMin;
6.   if tickRange div fFrequency > Width then
7.     Frequency := tickRange div Width;
8. end;  
9.  

This is off-topic, but I want to add a comment because I think that you are misunderstanding the meaning of the property "Frequency" here. Really, this property is named in a misleading way: in common sense, the word "frequency" implies: "High frequency -> many ticks". But it's the other way round: "High frequency --> less ticks"! The default parameters of a TrackBar have Max = 10 and Frequecy = 1 --> there are 10 intervals (or: 11 ticks). Now set the Frequeny higher to 2 - now we have LESS intervals (5, or 6 ticks). Therefore, the property should be understood as "TickIntervals"

Your calculation "tickRange / Width" is wrong because it calculates the number of intervals. You should do: "tickRange / Count" instead to determine the "Frequency" value.

[ASerge]

I committed a change of TTrackbar which picks up ASerge's post and switches to TickStyle = tsNone when the difference between Max and Min is > $3FFF (r61810)

I don't really like the current decision. Corrected property directly. The result is this code

Code: Pascal  [Select][+][-]

1. procedure TForm1.FormCreate(Sender: TObject);
2. begin
3.   TrackBar1.Max := MaxInt div 2;
4.   TrackBar1.Max := 5;
5. end;

does not work as

Code: Pascal  [Select][+][-]

1. procedure TForm1.FormCreate(Sender: TObject);
2. begin
3.   //TrackBar1.Max := MaxInt div 2;
4.   TrackBar1.Max := 5;
5. end;

It seems best to make a fix only at the level of calling widget interfaces without changing the property itself. In Delphi it is done this way.