Re: Checking for GUI overload

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

Ty wrote:
In a windows GUI-Application we visualize a datatable in a Grid. The
grid is updated by incoming data from the network.
From time to time it happens that there is too much information coming
in at once wich results in the gui becoming unresponsive for a minute
or so.

i've checked this and it's definitely because the gui-thread is not
fast enough to process the incoming messages realtime, therefore the
Windows MessageQueue is building up.

We can easily solve this by minimizing Refresh on the grid if too much
data is coming in. Right now we do exactly this by measuring the
incoming data. but we have to work with a hard value (xxx messsages/
second).

The messages are being "Post()"ed, meaning it's async. so the windows
messagequeue is building up. is it possible to get the current size of
this queue? so we could take action more dynamically. is there another
way of measuring responsiveness of a gui?

Not in .NET, no. But, you shouldn't need to.

IMHO, the solution to this sort of problem is to set a specific "refresh rate" for the UI that is strictly time-based (500 ms minimum, 1000 ms or more tends to work better). Then make sure the rest of the code is capable of handling the throughput, including being able to update the UI with however much data becomes available in the refresh period.

This is one of the few places where a polling strategy (use a timer, inspect the current state of the data) can definitely work better than an interrupt-driven one (invocation of data structure updates across threads).

If even at 500-1000 ms, you find the UI can't keep up, then you are simply trying to present too much information to the user at once.

There's no point in keeping the UI up-to-date if there's more information there than a human being can process, and a single thread on a modern PC can _definitely_ keep a properly-implemented UI up-to-date every half second or so. So, if even after throttling the refreshes, the UI still can't keep up with the data stream, then there's simply more data coming in than is worthwhile to present to the user.

Without knowing more about your specific scenario, it's hard to suggest what exactly is the right fix. Hopefully, just putting the UI update on a timer rather than trying to marshal each and every operation across the threads fixes the issue. But if not, you will have to look at just what information you're trying to present to the user so quickly that the UI thread can't even keep up.

Pete
.

Relevant Pages

  • Re: Grid Refresh!!!
    ... First download the new Atlas June CTP http://atlas.asp.net/ ... simple add a atlas:ScriptManager and involve the Grid ... add a timer and set the grid to refresh every ...
    (microsoft.public.dotnet.framework.aspnet.datagridcontrol)
  • Refresh of a DBGrid
    ... I have a DBGrid component showing the result of an ADOQuery. ... do a refresh in a timer to update the values in the grid. ... dont' want the grid to start showing the first record on top again. ...
    (borland.public.delphi.database.ado)
  • Re: Child grid woes
    ... pointer), but only with the wait statements running. ... in the grid refresh I've issued a NODEFAULT. ... insert into kid values ...
    (microsoft.public.fox.programmer.exchange)
  • Re: Child grid woes
    ... row of the child grid, then click the refresh button (which issues a form ... insert into kid values ...
    (microsoft.public.fox.programmer.exchange)
  • Re: Checking for GUI overload
    ... The Definitive Guide to Windows Installer ... grid is updated by incoming data from the network. ... IMHO, the solution to this sort of problem is to set a specific "refresh rate" for the UI that is strictly time-based. ... This is one of the few places where a polling strategy can definitely work better than an interrupt-driven one. ...
    (microsoft.public.dotnet.languages.csharp)