[Solved] Trackbar flickering

[d7_2_laz]

Ok; thanks wp for info!              // Win 10:   before: never after: never

[I’d think that’s comparibly irrelevant it there are 2 or 3 EraseBkgnd.  - Somehow strange.]

[Joanna]

Thanks so for the detailed explanation.

[wp]

Noticed that the FlagsEx patch in the win32 widgetset crashes the application under Win2000. The other solution, with handling the WM_ERASEBKGND message, however, works. These are the changes to be applied to win32wscomctrls.pp:

- Add this function:

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

1. function TrackbarWndProc(Window: HWnd; Msg: UInt; WParam: Windows.WParam;
2.   LParam: Windows.LParam): LResult; stdcall;   // <--- NEW FUNCTION
3. var
4.   Control: TWinControl;
5.   LMessage: TLMessage;
6. begin
7.   case Msg of
8.     // prevent flickering
9.     WM_ERASEBKGND:
10.       begin
11.         Control := GetWin32WindowInfo(Window)^.WinControl;
12.         LMessage.msg := Msg;
13.         LMessage.wParam := WParam;
14.         LMessage.lParam := LParam;
15.         LMessage.Result := 0;
16.         Result := DeliverMessage(Control, LMessage);
17.       end;
18.     else
19.       Result := WindowProc(Window, Msg, WParam, LParam);
20.   end;
21. end;

- Assign it to SubclassWndProc of TWin32WSTrackbar.CreateHandle (and remove the FlagsEx of previous patch):

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

1. class function TWin32WSTrackBar.CreateHandle(const AWinControl: TWinControl;
2.   const AParams: TCreateParams): HWND;
3. var
4.   Params: TCreateWindowExParams;
5. begin
6.   [...]
7.   with Params do
8.   begin
9.     //FlagsEx := FlagsEx or $02000000;   // <--- TO BE REMOVED
10.     pClassName := TRACKBAR_CLASS;
11.     WindowTitle := StrCaption;
12.     SubClassWndProc := @TrackbarWndProc;   // <--- TO BE ADDED
13.   end;
14.   // create window
15.   [...]
16. end;

[Joanna]

Thanks for the answers, someone from the forums gave me a simple solution in chat which does not require windows unit.

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

1. TMY_TRACKBAR = CLASS(TTrackBar)
2. STRICT PRIVATE
3.   PROCEDURE ERASEBACKGROUND(var Msg:TLMessage) ;MESSAGE LM_ERASEBKGND;
4. END;  
5.  
6. PROCEDURE TMY_TRACKBAR.ERASEBACKGROUND( VAR MSG: TLMESSAGE) ;
7.  BEGIN
8.    MSG.Result := 1;
9.  END;      

Apparently the flickering was being caused by the background being erased.

[d7_2_laz]

Hi wp, do you perhaps know, why in this internal subclassing patch an ordinary return of Msg.Result := 0 (1, ..)  won’t be sufficient, but an additiona DeliverMessage (having all parameters) would do the job; what’s the difference? Is an extra trigger of the message needed so that it gets respected by the sender?

[wp]

Maybe because the Windows-Message must be handled by the LCL system in the proper way? But I don't know, I just took what I found in the win32 widgetset code for other controls.

[Bart]

Maybe a WinProcess := False would suffice?

Bart

[wp]

Maybe a WinProcess := False would suffice?

No idea...

[d7_2_laz]

wp, oh I see. I’d never really paid full attention to this layer when dealing with “Result” in my subclassed window procedures, simply assuming it would be directly passed back to the API. And will keep an eye on in future. Thanks! For erasebkgnd, that might explain some sometimes a bit strange experiences with the return values (Result) for it. Will look more closely then how it cycles through the interface part.

Joanna, would the patch mentioned, seen for Win7, work for you native so that the additional helper is no longer needed?

[Joanna]

I’m not sure, I don’t know much about doing patches.
The simple solution which disables erase background works ok.

This makes me wonder why have erase background at all? If the appearance will be refreshed anyway why is it the default behavior to erase it first? I assume if only erase background is used I would see other programs under my program. I think I’ve seen thst in owner drawn combobox before I implemented the drawing code.

All this stuff is new to me

[d7_2_laz]

That's a message sent by Windows that it will erase the background now (and one might want to hook into or not). The erasure itself mostly might be appropriate, but sometimes it is surely not ….

The "Result := 1“ in this context does mean: “Windows, omit you erasure, I’ll do this myself   
  …..  (or not, if I like so)”  ..

[wp]

I’m not sure, I don’t know much about doing patches.

In the meantime, I applied the WM_EraseBkGnd fix to Laz/main, it has been merged to Laz/fixes and thus will be in Laz 3.4. Therefore, you will not have to apply any of these patches on your own once Laz 3.4 will have been released.

[440bx]

This makes me wonder why have erase background at all? If the appearance will be refreshed anyway why is it the default behavior to erase it first?

The answer to that is very simple.  Let's use an example to make it obvious.

Imagine you have a window with an image (smaller than the window) you want to keep centered in the window.  The crucial fact in that statement is "centered in the window", this means that every time the window is resized, the image has to move to be at the new center.

Now imagine that when the window size is changed, the background isn't erased.  What will happen is that part of image where the previous center used to be will remain there (because the background isn't erased) and part of it will be overpainted with the same image in the new window center.

To avoid having part of the image left in the window when it is resized, the background is erased. For an instant, the window has nothing in it (just the background color, whatever it may be) then, after the erase, the image is painted in the new center.  That two-step process, erase which leaves the background clear, followed by the painting of the image is the source of the flicker.  IOW, there would be no flicker if the background had not been erased but then, if the background is not erased and no "special measures" are taken then left overs of the previous image will be visible (which is undesirable.)

What can the special measures be ?... if you paint on a bitmap instead of the screen then you can lie to Windows (or whatever window manager you're using) and tell it that the background has been erased even though it hasn't.  The reason that will work is because, on the bitmap you're using as a window replacement, you'll first clear the bitmap then paint on it but, since the bitmap isn't visible until you paint it on the window, the clearing of the bitmap is not visible.  This process is what is commonly called "double buffering".

There are other ways to eliminate flicker without using "double buffering" (double buffering consumes memory for the bitmap it paints on which can potentially be large.)  One of those ways is to clear only those areas that need to be clear in the final screen.  To that effect there are plenty of techniques that can be used.  You can find some of them explained here: https://forum.lazarus.freepascal.org/index.php/topic,53791.0.html
along with example code you can step through using a debugger.

Now you should know why I inquired about the trackbar moving when the window is resized. if the trackbar doesn't move nor changes size then it is trivial to eliminate the flicker.  Study the examples if the reason why is still unclear to you at this time.

HTH.

[Joanna]

Wp I’m glad problem will be fixed.
All this talk about how things work reminds me of a problem I was having with tedit sometimes having the text not showing properly. I’m not sure what would make the text get lost inside the left part of the tedit. I can use the left arrow to get to it. Has anyone ever seen someone like that before.
I think I ended up having to reset the text to fix it.
Like text := text+’ ‘; text:= trim(text); strange workaround I know..