I’ve got an app in which a thread posts frequent state updates via a wx.CallAfter(pub.sendMessage) method for the main thread to use to update the gui, at the moment it’s posting these every 0.05 seconds.
Presumably though if run on a slow computer or if I did these updates too often or my gui update method was too slow, the thread would produce more events than the gui could consume at which point I guess the app would stop responding and probably wont recover as long as my thread keeps firing events.
Is there a way to avoid a potential pileup of progress events like this? As it’s only ever worthwhile for the gui to draw the latest state in this case, if there’s say 4 progress events in the main loops event queue, it may as well take the most recent and discard the older ones if it didn’t have time to use them in real time.
I guess I could flip the method so that the gui polls the state every so often, so this kind of problem wont occur, but I have a few cases where I force progress updates at certain times for key parts and disregard the 0.05 delay, which wont be known from the gui end.
Maybe this is just me over thinking though and this is a bit of a non-issue, but any ideas or insight will be useful
I’ve got an app in which a thread posts frequent state updates via a wx.CallAfter(pub.sendMessage) method for the main thread to use to update the gui, at the moment it’s posting these every 0.05 seconds.
Presumably though if run on a slow computer or if I did these updates too often or my gui update method was too slow, the thread would produce more events than the gui could consume at which point I guess the app would stop responding and probably wont recover as long as my thread keeps firing events.
Is there a way to avoid a potential pileup of progress events like this? As it’s only ever worthwhile for the gui to draw the latest state in this case, if there’s say 4 progress events in the main loops event queue, it may as well take the most recent and discard the older ones if it didn’t have time to use them in real time.
I guess I could flip the method so that the gui polls the state every so often, so this kind of problem wont occur, but I have a few cases where I force progress updates at certain times for key parts and disregard the 0.05 delay, which wont be known from the gui end.
Maybe this is just me over thinking though and this is a bit of a non-issue, but any ideas or insight will be useful
Usually, calling window.Refresh() will do this. Even if multiple refreshes happen in quick succession, it will only lead to one draw event. This uses the OS’s scheduling, so it should be the most efficient to ensure you’re drawing only when you have the resources. window.Update() can be used for when you need to draw right now. Are you doing all your drawing from paint events, or are you handling them some other way?
Regards,
Kevin
···
On Apr 23, 2013, at 7:58 AM, Paul Wiseman wrote:
Thanks,
Paul
–
You received this message because you are subscribed to the Google Groups “wxPython-users” group.
I’ve got an app in which a thread posts frequent state updates via a wx.CallAfter(pub.sendMessage) method for the main thread to use to update the gui, at the moment it’s posting these every 0.05 seconds.
Presumably though if run on a slow computer or if I did these updates too often or my gui update method was too slow, the thread would produce more events than the gui could consume at which point I guess the app would stop responding and probably wont recover as long as my thread keeps firing events.
Is there a way to avoid a potential pileup of progress events like this? As it’s only ever worthwhile for the gui to draw the latest state in this case, if there’s say 4 progress events in the main loops event queue, it may as well take the most recent and discard the older ones if it didn’t have time to use them in real time.
I guess I could flip the method so that the gui polls the state every so often, so this kind of problem wont occur, but I have a few cases where I force progress updates at certain times for key parts and disregard the 0.05 delay, which wont be known from the gui end.
Maybe this is just me over thinking though and this is a bit of a non-issue, but any ideas or insight will be useful
Usually, calling window.Refresh() will do this. Even if multiple refreshes happen in quick succession, it will only lead to one draw event. This uses the OS’s scheduling, so it should be the most efficient to ensure you’re drawing only when you have the resources. window.Update() can be used for when you need to draw right now. Are you doing all your drawing from paint events, or are you handling them some other way?
Regards,
Kevin
They’re mostly numbers and strings getting set to StaticTexts with SetLabel, there are some custom controls I call SetValue with which internally calls Refresh on itself. as well as a Layout call to cater for any changes.
I guess this is all using Refresh, so in that case you’re saying I’ll be safe to continue how I’m doing things? What if the parts other than drawing are too slow? For instance just the time it takes to run through the update handler subscribed to the pubsub message.
I’ve got an app in which a thread posts frequent state updates via a wx.CallAfter(pub.sendMessage) method for the main thread to use to update the gui, at the moment it’s posting these every 0.05 seconds.
Presumably though if run on a slow computer or if I did these updates too often or my gui update method was too slow, the thread would produce more events than the gui could consume at which point I guess the app would stop responding and probably wont recover as long as my thread keeps firing events.
Is there a way to avoid a potential pileup of progress events like this? As it’s only ever worthwhile for the gui to draw the latest state in this case, if there’s say 4 progress events in the main loops event queue, it may as well take the most recent and discard the older ones if it didn’t have time to use them in real time.
I guess I could flip the method so that the gui polls the state every so often, so this kind of problem wont occur, but I have a few cases where I force progress updates at certain times for key parts and disregard the 0.05 delay, which wont be known from the gui end.
Maybe this is just me over thinking though and this is a bit of a non-issue, but any ideas or insight will be useful
Usually, calling window.Refresh() will do this. Even if multiple refreshes happen in quick succession, it will only lead to one draw event. This uses the OS’s scheduling, so it should be the most efficient to ensure you’re drawing only when you have the resources. window.Update() can be used for when you need to draw right now. Are you doing all your drawing from paint events, or are you handling them some other way?
Regards,
Kevin
They’re mostly numbers and strings getting set to StaticTexts with SetLabel, there are some custom controls I call SetValue with which internally calls Refresh on itself. as well as a Layout call to cater for any changes.
I guess this is all using Refresh, so in that case you’re saying I’ll be safe to continue how I’m doing things? What if the parts other than drawing are too slow? For instance just the time it takes to run through the update handler subscribed to the pubsub message.
I wouldn’t worry until you have specific reports of problems. With performance problems, the fix depends very heavily on precisely what code is slowing things down, and usually the only way you can deduce that is via profiling. If you’re really concerned about the app having performance problems that may only occur on slower machines, I’d build in some app setting / flag that can run the app with profiling enabled (using e.g. cProfile) and send you the performance data when the run completes, that the user can turn on when they start hitting performance issues.
Why not have a get published data method that just updates a single
set of stored values of the data and sets a redraw needed flag.
That should be fast and any complicated work can be done once per
redraw.
···
On 23/04/13 15:58, Paul Wiseman wrote:
Hey,
I've got an app in which a thread posts frequent state
updates via a wx.CallAfter(pub.sendMessage) method for the main
thread to use to update the gui, at the moment it’s posting
these every 0.05 seconds.
Presumably though if run on a slow computer or if I did these
updates too often or my gui update method was too slow, the
thread would produce more events than the gui could consume at
which point I guess the app would stop responding and probably
wont recover as long as my thread keeps firing events.
Is there a way to avoid a potential pileup of progress events
like this? As it’s only ever worthwhile for the gui to draw the
latest state in this case, if there’s say 4 progress events in
the main loops event queue, it may as well take the most recent
and discard the older ones if it didn’t have time to use them in
real time.
I guess I could flip the method so that the gui polls the
state every so often, so this kind of problem wont occur, but I
have a few cases where I force progress updates at certain times
for key parts and disregard the 0.05 delay, which wont be known
from the gui end.
Maybe this is just me over thinking though and this is a bit
of a non-issue, but any ideas or insight will be useful
Thanks,
Paul
–
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,
I've got an app in which a thread posts frequent state
updates via a wx.CallAfter(pub.sendMessage) method for the main
thread to use to update the gui, at the moment it’s posting
these every 0.05 seconds.
Presumably though if run on a slow computer or if I did these
updates too often or my gui update method was too slow, the
thread would produce more events than the gui could consume at
which point I guess the app would stop responding and probably
wont recover as long as my thread keeps firing events.
Is there a way to avoid a potential pileup of progress events
like this? As it’s only ever worthwhile for the gui to draw the
latest state in this case, if there’s say 4 progress events in
the main loops event queue, it may as well take the most recent
and discard the older ones if it didn’t have time to use them in
real time.
I guess I could flip the method so that the gui polls the
state every so often, so this kind of problem wont occur, but I
have a few cases where I force progress updates at certain times
for key parts and disregard the 0.05 delay, which wont be known
from the gui end.
Maybe this is just me over thinking though and this is a bit
of a non-issue, but any ideas or insight will be useful
Thanks,
Paul
–
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,
I’ve got an app in which a thread posts frequent state updates via a wx.CallAfter(pub.sendMessage) method for the main thread to use to update the gui, at the moment it’s posting these every 0.05 seconds.
Presumably though if run on a slow computer or if I did these updates too often or my gui update method was too slow, the thread would produce more events than the gui could consume at which point I guess the app would stop responding and probably wont recover as long as my thread keeps firing events.
Is there a way to avoid a potential pileup of progress events like this? As it’s only ever worthwhile for the gui to draw the latest state in this case, if there’s say 4 progress events in the main loops event queue, it may as well take the most recent and discard the older ones if it didn’t have time to use them in real time.
I guess I could flip the method so that the gui polls the state every so often, so this kind of problem wont occur, but I have a few cases where I force progress updates at certain times for key parts and disregard the 0.05 delay, which wont be known from the gui end.
Maybe this is just me over thinking though and this is a bit of a non-issue, but any ideas or insight will be useful
Usually, calling window.Refresh() will do this. Even if multiple refreshes happen in quick succession, it will only lead to one draw event. This uses the OS’s scheduling, so it should be the most efficient to ensure you’re drawing only when you have the resources. window.Update() can be used for when you need to draw right now. Are you doing all your drawing from paint events, or are you handling them some other way?
Regards,
Kevin
They’re mostly numbers and strings getting set to StaticTexts with SetLabel, there are some custom controls I call SetValue with which internally calls Refresh on itself. as well as a Layout call to cater for any changes.
I guess this is all using Refresh, so in that case you’re saying I’ll be safe to continue how I’m doing things? What if the parts other than drawing are too slow? For instance just the time it takes to run through the update handler subscribed to the pubsub message.
I wouldn’t worry until you have specific reports of problems. With performance problems, the fix depends very heavily on precisely what code is slowing things down, and usually the only way you can deduce that is via profiling. If you’re really concerned about the app having performance problems that may only occur on slower machines, I’d build in some app setting / flag that can run the app with profiling enabled (using e.g. cProfile) and send you the performance data when the run completes, that the user can turn on when they start hitting performance issues.
I’m just worried if it hits a tipping point it will become unrecoverable as a pile up of progress events will potentially build up, and it will get further and further behind the real time state. I guess I can slow down the handler that receives the data from the pubsub message and see what happens. I really like the profiling idea, that’s definitely going on the TODO list thanks!
I’ve got an app in which a thread posts frequent state updates via a wx.CallAfter(pub.sendMessage) method for the main thread to use to update the gui, at the moment it’s posting these every 0.05 seconds.
Presumably though if run on a slow computer or if I did these updates too often or my gui update method was too slow, the thread would produce more events than the gui could consume at which point I guess the app would stop responding and probably wont recover as long as my thread keeps firing events.
Is there a way to avoid a potential pileup of progress events like this? As it’s only ever worthwhile for the gui to draw the latest state in this case, if there’s say 4 progress events in the main loops event queue, it may as well take the most recent and discard the older ones if it didn’t have time to use them in real time.
I guess I could flip the method so that the gui polls the state every so often, so this kind of problem wont occur, but I have a few cases where I force progress updates at certain times for key parts and disregard the 0.05 delay, which wont be known from the gui end.
Maybe this is just me over thinking though and this is a bit of a non-issue, but any ideas or insight will be useful
Usually, calling window.Refresh() will do this. Even if multiple refreshes happen in quick succession, it will only lead to one draw event. This uses the OS’s scheduling, so it should be the most efficient to ensure you’re drawing only when you have the resources. window.Update() can be used for when you need to draw right now. Are you doing all your drawing from paint events, or are you handling them some other way?
Regards,
Kevin
They’re mostly numbers and strings getting set to StaticTexts with SetLabel, there are some custom controls I call SetValue with which internally calls Refresh on itself. as well as a Layout call to cater for any changes.
I guess this is all using Refresh, so in that case you’re saying I’ll be safe to continue how I’m doing things? What if the parts other than drawing are too slow? For instance just the time it takes to run through the update handler subscribed to the pubsub message.
I wouldn’t worry until you have specific reports of problems. With performance problems, the fix depends very heavily on precisely what code is slowing things down, and usually the only way you can deduce that is via profiling. If you’re really concerned about the app having performance problems that may only occur on slower machines, I’d build in some app setting / flag that can run the app with profiling enabled (using e.g. cProfile) and send you the performance data when the run completes, that the user can turn on when they start hitting performance issues.
I’m just worried if it hits a tipping point it will become unrecoverable as a pile up of progress events will potentially build up, and it will get further and further behind the real time state. I guess I can slow down the handler that receives the data from the pubsub message and see what happens. I really like the profiling idea, that’s definitely going on the TODO list thanks!
The native controls are very efficient about drawing, internally the native controls are setting ‘needs drawing’ flags and then redrawing when there’s a free cycle, rather than making each refresh correspond to a redraw. If you’re doing custom drawing (i.e. you’re handling EVT_PAINT and drawing using wx.DC derived classes to paint the control yourself), then you do have to be sure to use Refresh() and Update() properly to make sure drawing is efficient, but otherwise, the native controls handle this for you. 0.05 for refresh cycles is not particularly aggressive, BTW.
Decide a required update rate, a multiple of 20 mS but for anything
but video/music between 100 & 300 msecs will count as
responsive, and set a timer - when the timer triggers check the
update flag and refresh changed data.
state updates via a wx.CallAfter(pub.sendMessage)
method for the main thread to use to update the gui,
at the moment it’s posting these every 0.05 seconds.
Presumably though if run on a slow computer or if
I did these updates too often or my gui update
method was too slow, the thread would produce more
events than the gui could consume at which point I
guess the app would stop responding and probably
wont recover as long as my thread keeps firing
events.
Is there a way to avoid a potential pileup of
progress events like this? As it’s only ever
worthwhile for the gui to draw the latest state in
this case, if there’s say 4 progress events in the
main loops event queue, it may as well take the most
recent and discard the older ones if it didn’t have
time to use them in real time.
I guess I could flip the method so that the gui
polls the state every so often, so this kind of
problem wont occur, but I have a few cases where I
force progress updates at certain times for key
parts and disregard the 0.05 delay, which wont be
known from the gui end.
Maybe this is just me over thinking though and
this is a bit of a non-issue, but any ideas or
insight will be useful
Thanks,
Paul
–
You received this message because you are subscribed to
the Google Groups “wxPython-users” group.
To unsubscribe from this group and stop receiving emails
