Windows with many controls paint slowly on Windows lazarus / 31-LCL ---------------------------------------------------------------------- willbprog9933 · 2017-11-29 07:50 Greetings everyone, Hopefully this is the correct forum to post under.  Please forgive me if it's not. My limited time I've had to explore Lazarus and make a few test programs has been enjoyable.  While I've personally been using Lazarus on Linux, I have a VB6 app I'd like to migrate over for my customers on Windows.  Some of the screens on this app have 100+ controls on them (yes, not good practice but customer-dictated).  The VB6 runtime paints these windows completely and quickly while the executable compiled on Lazarus / Windows paints a bit slowly in comparison.  Here are three frames from a video capture of the Lazarus / Windows being restored from being minimized (providing a link because the image is somewhat large): Animated GIF showing painting progression As you can see, the painting takes a while, compared to VB6 and Java running on the same machine with 100+ similar controls.  VB6 and Java apps with windows that contain the same amount of controls appear with no noticeable delay.  The only thing that paints slower is a .Net app with the same amount of controls -- it's painfully slow when painting -- much slower than Free Pascal / LCL. The executable I compiled was set with debug options off.  I tried explicitly disabling and enabling double-buffering for the form, but no difference was seen.  There is no code behind the Free Pascal window shown above, just the controls. I'm running all of these test apps on a Windows 7 virtual machine (VirtualBox) and have also verified that everything behaves the same on Windows 7 running on 'bare metal'.  I have a decent AMD video card, my system has an eight-core processor topping out at 4 GHz and 16 GB of RAM, with the VM given 4 GB of RAM, so no resource starvation. Is there anything I can do to speed up Free Pascal / LCL's drawing on Windows?  On Linux / X11, the same form with hundreds of controls shows almost immediately with no slow painting. Thank you! ---------------------------------------------------------------------- Handoko · 2017-11-29 08:38 Can you please provide us the compile-able source code for us to inspect. Here has many seniors who will be happy to help you, I believe your problem will be solved. If you do not wish to publish the project, you can write a demo that showing that issue. Compress all the necessaries files except the binary, *.bak and lib folder and send the zip file to this forum. ---------------------------------------------------------------------- Eugene Loza · 2017-11-29 09:47 I've had the same issue when trying to develop a minesweeper game ~1000 controls take several seconds to create/init. https://github.com/eugeneloza/Metar-Sweeper ---------------------------------------------------------------------- balazsszekely · 2017-11-29 10:08 Catch WMEnterSizeMove, WMExitSizeMove messages then disable window update between them. ---------------------------------------------------------------------- avra · 2017-11-29 10:17 Quote from: willbprog9933 on November 29, 2017, 08:50:38 amIs there anything I can do to speed up Free Pascal / LCL's drawing on Windows?  On Linux / X11, the same form with hundreds of controls shows almost immediately with no slow painting.Maybe you can find an inspiration here: https://stackoverflow.com/questions/3792217/how-can-i-disable-screen- update-which-updating-a-lot-of-controls http://www.festra.com/eng/tip-beginupdate.htm ---------------------------------------------------------------------- willbprog9933 · 2017-11-29 16:53 Thank you everyone for your response!  I was very pleased to see so many replies!  I will try the suggestions and let you know! @Handoko, as noted in my original post, there is no code, just the one form with the many controls.  It actually *is* a test project. ---------------------------------------------------------------------- wp · 2017-11-29 17:16 QuoteIt actually *is* a test project.Then why don't you upload it? Such a simple project would just be perfect, and we all would know exactly what you are talking about... In the mean time I wrote my own project for this issue, just straightforward, no tricks. Well - maybe there is some sluggish reaction when the form loads, but I would not complain about it seriously. Is your program behaving like mine? How do you paint the background image? Without the background image the labels and edits appear immediately. ---------------------------------------------------------------------- willbprog9933 · 2017-11-29 18:06 Quote from: wp on November 29, 2017, 06:16:40 pmThen why don't you upload it? Such a simple project would just be perfect, and we all would know exactly what you are talking about... Because it's top-secret...must make you sign an NDA   Just kidding.  I will do that as soon as I can... ---------------------------------------------------------------------- willbprog9933 · 2017-11-29 18:25 Quote from: wp on November 29, 2017, 06:16:40 pmThen why don't you upload it? Such a simple project would just be perfect, and we all would know exactly what you are talking about... Here it is.  Thanks for your patience! ---------------------------------------------------------------------- Remy Lebeau · 2017-11-29 18:29 Quote from: Eugene Loza on November 29, 2017, 10:47:10 amI've had the same issue when trying to develop a minesweeper game ~1000 controls take several seconds to create/init. https://github.com/eugeneloza/Metar-Sweeper That is because you are using TPanel (a *windowed* control) for your boxes.  Each panel takes up an HWND handle, and thus has system resources behind it.  Try switching to TImage instead (a *graphical* control) and you will likely see a HUGH improvement in performance.  The fewer *windowed* controls you have, the faster things can create and paint.  This is why high-performance apps, like web browsers, games, etc don't use a lot of windowed controls to begin with. ---------------------------------------------------------------------- wp · 2017-11-29 18:36 Quote from: willbprog9933 on November 29, 2017, 07:25:36 pmHere it is.  It this slow? The form comes up immediately. Where is the background image? What exactly are you doing when you see the speed issue? ---------------------------------------------------------------------- willbprog9933 · 2017-11-29 18:50 Quote from: Remy Lebeau on November 29, 2017, 07:29:05 pmThat is because you are using TPanel (a *windowed* control) for your boxes.  Each panel takes up an HWND handle, and thus has system resources behind it. Oh yes, this is so true.  When I first got into Win API programming using C, I tried writing up a GUI form editor using *real* controls instead of drawn copies of them.   I exhausted my HWND handles quickly and found it was very slow.  Drawing the controls instead of making instances of them made a really positive difference. ---------------------------------------------------------------------- willbprog9933 · 2017-11-29 18:53 Quote from: wp on November 29, 2017, 07:36:22 pmIt this slow? The form comes up immediately. Where is the background image? What exactly are you doing when you see the speed issue? I am not using a background image.  The form paints slow on my hardware, both virtualized and non-virtualized, as shown in the animated GIF above.  I can provide the actual video, if that would be helpful? ---------------------------------------------------------------------- willbprog9933 · 2017-11-29 19:09 Hi again, Here is the video capture that I derived the animated GIF from.  In the video, I restore and minimize the form from the Free Pascal demo project I made a few times, and you can see the slow drawing.  Later, I restore and minimize a demo Java app with the same amount of controls, which shows absolutely zero drawing latency. Video capture of slow form drawing ---------------------------------------------------------------------- Remy Lebeau · 2017-11-29 19:25 Quote from: willbprog9933 on November 29, 2017, 07:50:24 pmOh yes, this is so true.  When I first got into Win API programming using C, I tried writing up a GUI form editor using *real* controls instead of drawn copies of them.   I exhausted my HWND handles quickly and found it was very slow.  Drawing the controls instead of making instances of them made a really positive difference. I did something similar once.  I had an old app that used hundreds of colored TPanel controls as status lights.  UI updates were a bit slow and resource-intensive.  So I wrote a custom TGraphicControl component (*) to display the status lights (and since the lights were being displayed in groups, I made the control able to display a whole group at a time).  I was able to replace those hundreds of Panels with a dozen graphic controls, and the UI was vastly faster and its resource usage dropped like 45%! (* and then I made a screensaver of flashing lights and patterns using just one instance of that graphic control ) ---------------------------------------------------------------------- wp · 2017-11-29 21:07 Quote from: willbprog9933 on November 29, 2017, 08:09:21 pmHi again, Here is the video capture that I derived the animated GIF from.  In the video, I restore and minimize the form from the Free Pascal demo project I made a few times, and you can see the slow drawing.  Later, I restore and minimize a demo Java app with the same amount of controls, which shows absolutely zero drawing latency. Video capture of slow form drawing I was confused by the screen background image. So you mean the very short delay, maybe 0.1 sec or less, during which all controls build up? ---------------------------------------------------------------------- taazz · 2017-11-29 21:24 Quote from: wp on November 29, 2017, 10:07:40 pmQuote from: willbprog9933 on November 29, 2017, 08:09:21 pmHi again, Here is the video capture that I derived the animated GIF from.  In the video, I restore and minimize the form from the Free Pascal demo project I made a few times, and you can see the slow drawing.  Later, I restore and minimize a demo Java app with the same amount of controls, which shows absolutely zero drawing latency. Video capture of slow form drawing I was confused by the screen background image. So you mean the very short delay, maybe 0.1 sec or less, during which all controls build up? which is slower than java! which shows a problem on the design or implementation. Slower than java? really? and that is not a problem? ---------------------------------------------------------------------- willbprog9933 · 2017-11-29 22:30 Quote from: wp on November 29, 2017, 10:07:40 pmI was confused by the screen background image. So you mean the very short delay, maybe 0.1 sec or less, during which all controls build up? Yes, that's correct.  I am not using a background image on my form, but the desktop pic is showing through while the form builds up. ---------------------------------------------------------------------- wp · 2017-11-29 23:35 Background image showing through? I don't see this here on Win 10. Setting several breakpoints somewhere during the painting cycle I get the impression that at first a white form background is painted, then the border of the edits is drawn, and finally the formbackground becomes gray (clBtnFace) and the labels appear. The quick alteration from white to gray background certainly is perceived as flicker. My Win7-VM is not as fast as yours but I think that the background shows through there too. This difference could be due to the Aero effects of Win7. What if you turn Aero off? ---------------------------------------------------------------------- willbprog9933 · 2017-11-29 23:51 Quote from: wp on November 30, 2017, 12:35:33 amMy Win7-VM is not as fast as yours but I think that the background shows through there too. This difference could be due to the Aero effects of Win7. What if you turn Aero off? This is with Aero off.  I don't like Aero myself, so that was already turned off years ago. Looks like I'll just have to ignore this, then.  It bugs me greatly but one of my colleagues says he barely notices it.  It's possible my brain is unusually sensitive to this slow painting while other's don't see it at all.  It might explain why I'm the only one who thinks X11 is slow on Debian while on other distros it's fine. :shrugs: ---------------------------------------------------------------------- Josh · 2017-11-30 03:05 Hi Have you tried setting the form doublebuffering to true in the form on create event, this should help any flicker. ypu could also try placing all the controls on a panel, and have the panel visibility set to false in design time, then on form onshow event make the panel visible; this would work better if the panels doublebuffering was set to true also. Quick mod of your app, if you can try it it may be ok. ---------------------------------------------------------------------- willbprog9933 · 2017-11-30 05:03 Quote from: josh on November 30, 2017, 04:05:08 amHave you tried setting the form doublebuffering to true in the form on create event, this should help any flicker. ypu could also try placing all the controls on a panel, and have the panel visibility set to false in design time, then on form onshow event make the panel visible; this would work better if the panels doublebuffering was set to true also. Hi Josh, Thanks for the modded project.  When compiled, it does paint a little quicker, with a less noticeable draw time than my original one, so thanks for giving me those pointers!  I did try the DoubleBuffering before, but only on the form and not on panels. Thanks again! ---------------------------------------------------------------------- wp · 2017-11-30 08:26 I converted your project from reply #8 to Delphi, and my impression is that its exe behaves in the same way as the Lazarus exe. It's hard to see, though. ---------------------------------------------------------------------- willbprog9933 · 2017-11-30 16:49 Quote from: wp on November 30, 2017, 09:26:26 amI converted your project from reply #8 to Delphi, and my impression is that its exe behaves in the same way as the Lazarus exe. It's hard to see, though. Thank you wp   I'll just have to deal with it.  As mentioned before, my closest colleague says the painting slowness isn't that noticeable to him, and others here have echoed that, so I'll just tolerate it, I guess.