Re: Responsive Splash Screen while creating GUI objects
Andrea Gavana <[email protected]>
| Newsgroups | gmane.comp.python.wxpython |
|---|---|
| Message-ID | <CAEf70bxWWmMAmKgnZSTcizZ4mZ4HMBwm7L5mWpUKs91mNLVwTA@mail.gmail.com> |
On Thu, 14 May 2020 at 16.27, Jasper Alexion <[email protected]> wrote: > Thanks everybody, these are some great suggestions. > > > For us personally it is also very satisfying to see these suggestions > because we’ve tried all of them before asking this question. We are > definitely on the same page.😊 Multiprocessing is currently our plan B > and using ‘wx.Yield()’ is plan C. > > > Still, all these ideas work around the problem of having responsive GUI > while creating more GUI objects. Is it safe to assume that this is a known > limitation or wxPython? Or do we need to dig deeper? > > > The reason we’re not a fan of using multiprocessing is because it uses wx > in a way it’s not supposed to be used. This feels like asking for trouble > in the future. > > > The problem with using ‘wx.Yield()’ is that it’s just a one time event. > The Splash Screen does update, but it will be sporadic and things like a > wx.Gauge will look jerky instead of smooth. > > I think it depends on how often you update your gauge - I.e., how many events you send. Our main application loads in about 2 seconds but we still have the splash screens - as in older machines it used to take 5/6 seconds, and our custom gauge+text looked very much good enough. We launch an event every time a module containing GUI things is imported. If you think this Is still not acceptable for you, then multiprocessing is your only way as far as I can see. Only the GUI thread can create and interact with GUI elements, so you’re kind of stuck in a race between updating the splash screen and creating other elements. This is not a limitation of wxPython, the OS dictates that. In the end, the splash screen is just another eye candy, and I am somewhat unconvinced that it is the main issue at hand with your app. Andrea. > > > On Thursday, May 14, 2020 at 2:58:07 PM UTC+2, Gadget Steve wrote: > >> Just a suggestion but you could possibly consider using multiprocessing >> to create a launcher app that creates the splash screen & then a >> multiprocessing manager that launches your main app, (possibly hidden), and >> uses a multiprocessing manager to get progress from the main if this is >> needed &/or post some options or cancel events from the splash screen. >> >> >> >> Then once your main app signifies that it is ready to go you can display >> it and hide the launcher app. (I know of several programs that do this sort >> of thing). It may even be possible to exit the launcher app and leave the >> main app running. >> >> >> >> This should be a lot less refactoring. >> >> >> >> Steve Barnes >> >> >> >> *From:* [email protected] <[email protected]> *On >> Behalf Of *Jasper Alexion >> *Sent:* 14 May 2020 12:55 >> *To:* wxPython-users <[email protected]> >> *Subject:* Re: [wxPython-users] Responsive Splash Screen while creating >> GUI objects >> >> >> >> Thanks again for the great suggestions. It is much appreciated. >> >> >> >> I totally agree that having a more dynamically built GUI is a far better >> solution. However, with our current codebase this is simply not possible. >> If we would invest all our time in refactoring our current codebase to make >> this possible it would take us at least 1 year. We are actively working >> towards this goal, investing a percentage of our time, but for right now we >> will have to deal with a large GUI that takes at least 10 seconds to create. >> >> >> >> >> Besides that, I would argue that having a responsive splash screen is >> still a goal worth trying to achieve even if the loading time of the GUI is >> just a couple of seconds. Or in other words: we prefer to have our >> application be responsive at all times. >> >> >> >> The core of the problem seems to be the creation of GUI during the Splash >> screen. All the Splash screen examples we have found online assume that the >> “worker thread” is doing non-gui work, which is simulated by things like >> calling ‘time.sleep()’. >> >> >> >> All advice we’ve received so far is pointing towards solutions that work >> around this core problem. We are still very interested in a solution. >> >> >> >> On Wednesday, May 13, 2020 at 6:58:20 PM UTC+2, Infinity77 wrote: >> >> On Wed, 13 May 2020 at 18.54, Charles McKnight <[email protected]> >> wrote: >> >> Hi Jasper, >> >> >> >> I am not sure of what your application is doing, but having built >> relatively large applications I would ask whether or not all of those >> objects need to be created at the same time. One of the approaches I’ve >> taken in the past with this type of thing is referred to as lazy >> initialization. The practice is to create the objects that will be >> immediately used and then to continue to create the other objects in the >> background so that the application appears to be more responsive. Again, >> I’m not sure what your application is doing that requires that many objects >> to be created initially, so this solution may not work for you. >> >> >> >> You also mention that you have run a profiler to determine that the bulk >> of the time is in creating the GUI. Is there a particular place in the GUI >> code that is consuming the most time? >> >> >> >> Regards, >> >> >> >> Charles >> >> >> >> >> >> This is a very good answer, and in practice I use it all the time myself. >> Maybe you have many windows that do not need to be shown straight away? Or >> notebook pages that you can create on the fly when the user switches to one >> of them? A combination of Freeze/Thaw can do miracles in these cases. >> >> >> >> Andrea. >> >> >> >> >> >> >> >> >> >> On May 13, 2020, at 7:42 AM, Jasper Alexion <[email protected]> wrote: >> >> >> >> Thank you for your advice. It is much appreciated. >> >> >> >> A couple of points: >> >> 1. Our application contains thousands of GUI objects, which is >> significantly slower than the 900 you tested with. We use roughly 3000 GDI >> objects and 5000 USER objects in Windows 10. We know this is far from >> optimal, and we are working towards lowering this in the future. >> >> 2. In my question I stated that the work to be done as purely >> building GUI. This is an oversimplification. We do have database queries >> and internal business logic that also takes time. However, by using a >> profiler we have determined that the creation of the GUI by far the most >> time consuming >> >> >> >> In short: We are sure it’s the GUI that’s taking the majority of the time >> >> >> >> >> >> >> On Tuesday, May 12, 2020 at 10:10:44 PM UTC+2, johnf wrote: >> >> I created a reasonably large app and was concerned about how long the app >> was taking to load. So, as an experiment I create a frame with approx. 900 >> objects on a scroll panel. It loaded in just a couple seconds - some times >> less on a windows 10 box. It made me realize that it was not the wxPython >> GUI objects that was taking the time but my database connections. I wonder >> if you are having the same issue as I did? >> >> Python 3.6, wxPython 4.0.7, windows 10. >> >> Johnf >> >> On 5/12/20 7:03 AM, Jasper Alexion wrote: >> >> Hello, >> >> >> >> We are currently in the process of creating a splash screen for our >> application and we are encountering a problem that causes the GUI to become >> unresponsive. >> >> >> >> Our application has a very large GUI containing thousands of fields and >> labels. Creating this GUI takes around 10 seconds. In the long term we are >> working towards redesigning our application more towards MVC, but as of now >> it is impossible to dynamically create the GUI when needed. >> >> >> >> Goal: >> >> 1. We want a responsive splash screen while our application is >> starting. >> >> 2. Responsive means: draggable window, moving wx.Gauge, etc.. >> >> 1. >> >> 2. >> >> >> >> Problem: >> >> 1. We can only create GUI objects from the GUI-thread that runs >> the mainloop >> >> 2. When the mainloop is busy creating GUI objects, the WHOLE >> application (at least the GUI part) freezes. >> >> 1. >> >> 2. >> >> >> >> Notes >> >> 1. We could use wx.Yield() to let the splash screen update itself. >> However, this would result in a splash screen that sporadically updates at >> random moments instead of being responsive at all times with a nice smooth >> flowing wx.Gauge >> >> 2. We are using threads (wx.Timer,wx.PostEvent,wx.CallAfter) to >> keep (parts of the) splash screen responsive, this works well during normal >> operation. However, as soon as the mainloop is too busy to handle wx events >> the whole GUI freezes. >> >> 1. >> >> 2. >> >> How could we achieve this? >> >> >> >> We are using Python 3.8.2 and the following libraries: >> >> numpy==1.18.4 >> Pillow==7.1.2 >> Pypubsub==4.0.3 >> six==1.14.0 >> wxPython==4.1.0 >> >> >> >> Thanks in advance, >> >> Jasper >> >> -- >> You received this message because you are subscribed to the Google Groups >> "wxPython-users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/wxpython-users/bf3743b8-79d1-463d-8b78-d447e206377a%40googlegroups.com >> <https://groups.google.com/d/msgid/wxpython-users/bf3743b8-79d1-463d-8b78-d447e206377a%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> >> >> >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "wxPython-users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/wxpython-users/f40b8cd9-84d5-4d52-af02-dfd135fc8c0d%40googlegroups.com >> <https://groups.google.com/d/msgid/wxpython-users/f40b8cd9-84d5-4d52-af02-dfd135fc8c0d%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "wxPython-users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/wxpython-users/26184C06-44CB-4B72-9BF5-79299814CB7B%40gmail.com >> <https://groups.google.com/d/msgid/wxpython-users/26184C06-44CB-4B72-9BF5-79299814CB7B%40gmail.com?utm_medium=email&utm_source=footer> >> . >> >> -- >> You received this message because you are subscribed to the Google Groups >> "wxPython-users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> > To view this discussion on the web visit >> https://groups.google.com/d/msgid/wxpython-users/e5ff24a5-beff-4148-8b3b-c8d062912463%40googlegroups.com >> <https://groups.google.com/d/msgid/wxpython-users/e5ff24a5-beff-4148-8b3b-c8d062912463%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- > You received this message because you are subscribed to the Google Groups > "wxPython-users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/wxpython-users/ecad069c-237c-4936-843d-695a824f89c5%40googlegroups.com > <https://groups.google.com/d/msgid/wxpython-users/ecad069c-237c-4936-843d-695a824f89c5%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "wxPython-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/wxpython-users/CAEf70bxWWmMAmKgnZSTcizZ4mZ4HMBwm7L5mWpUKs91mNLVwTA%40mail.gmail.com.