1

Using Delphi Seattle, take the following code with a button and a label and set the Form's DoubleBuffering to True.

procedure TForm1.Button1Click(Sender: TObject);
Var a: Integer;
    s: Int64;
begin
  s := GetTickCount;
  for a := 1 to 10000 do begin
    Label1.Caption := 'Testing '+IntToStr(a);
    Application.ProcessMessages;
  end;
  s := GetTickCount - s;
  caption := inttostr(s);
end;

Besides heavy flickering, the loop takes much longer if a VCL style is used. Same happens with other controls i.e TGroupBox, TStatusBar. Updating the form Caption instead has no flickering, but it's much slower.

How can I fix the flickering?

Update from comments:

The code is just to easily reproduce the issue. The problem I encountered is in a part of large application where a file download is performed and the progress updated as the data received event is triggered, i.e " 12.05 MB / 200 MB done". The performance degrade (and flickering) is so bad with a custom VCL style on that the download was faster when on default "Windows" style.

LU RD
  • 34,438
  • 5
  • 88
  • 296
hikari
  • 3,393
  • 1
  • 33
  • 72
  • 1
    Lots of duplicates: http://stackoverflow.com/search?q=%5Bdelphi%5D+flicker – Disillusioned Apr 18 '16 at 05:14
  • Not even 1 duplicate, read the question fully again. – hikari Apr 18 '16 at 05:16
  • 3
    Use `TStaticText` instead of `TLabel`. – LU RD Apr 18 '16 at 05:24
  • See [TLabel and TGroupbox Captions Flicker on Resize](http://stackoverflow.com/questions/8058745/tlabel-and-tgroupbox-captions-flicker-on-resize). – LU RD Apr 18 '16 at 05:37
  • @LURD that link earned my answer a DV. Perhaps the asker is disappointed that VCL styles don't yield so easily. Or perhaps the code there is too involved to implement easily. – David Heffernan Apr 18 '16 at 07:18
  • 2
    @DavidHeffernan, true. DoubleBuffering is seldom the solution to flickering, and as you say, it can be a bit complex to handle flickering in general. The example here is not taken from a real application. How can the performance be a problem then? And without knowing the real problem, how can this question get an answer? – LU RD Apr 18 '16 at 07:36
  • The code is just to easily reproduce the issue. The problem I encountered is in a part of large application where a file download is performed and the progress updated as the data received event is triggered, i.e " 12.05 MB / 200 MB done". The performance degrade (and flickering) is so bad with a custom VCL style on that the download was faster when on default "Windows" style. – hikari Apr 18 '16 at 10:31
  • @hikari _First things first_ Instead advising me to read your question again, your time would be better spent considering the answers in the link I provided. It is not our responsibility to repeat those answers here. As the person coming hat in hand seeking assistance, the least you could do is explain what you've tried of those many suggestions, and why they don't work. – Disillusioned Apr 18 '16 at 12:40
  • And secondly, your previous comment might as well be part of your question. It is highly relevant given your unrealistic code snippet to reproduce the problem. In fact, it leads me to suggest that you should consider re-examining your entire approach.... If you're going to perform very many intensive (i.e. Styles enabled) GUI operations (i.e. updates every few ms) inline with a task you want to run quickly .... you can ***expect*** that task to slow down. (Granted there may be inefficiencies slowing things down more than necessary, but you're still better off avoiding it in the first place.) – Disillusioned Apr 18 '16 at 12:49
  • 2
    So... Do your download without trying to update display on every packet (which is probably unreadable in any case). And instead only update the display every 1/2 second. – Disillusioned Apr 18 '16 at 12:51
  • don't use Application.ProcessMessages; instead try Label1.repaint; – RoutineOp Apr 20 '16 at 16:59

0 Answers0