Re: Responsive Splash Screen while creating GUI objects

On Thu, 14 May 2020 at 13.55, Jasper Alexion <[email protected]>
wrote:

> 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.
>

What I do in these cases is:

1. Create the splash screen inside a class derived from wx.App - and before
anything else. I generally use a modified version of wx.lib.advancedsplash
where I draw a progress bar and text myself

2. Register the splash screen to listen to specific events - maybe using
pubsub, although I found a less heavy alternative

3. While creating other GUI elements in other parts of the code,
systematically and strategically send custom events to which the splash
screen reacts, Yield() for them.

4. Kill the splash screen right after the main frame is shown.

Andrea.


>
>
> 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.
>>>>       1.
>>>>
>>>>
>>>>
>>>> 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.
>>>>       1.
>>>>
>>>>
>>>>
>>>> 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.
>>>>       1.
>>>>
>>>> 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/CAEf70bzHLXm7dG5QO%2Ba16Frj2eV8aWyudKc5EVJuuUAQjAEZhw%40mail.gmail.com.