Can we create multiple message maps in a Dialog?
-
I've ran into a situation where ::PostMessage was over-flowing the message queue buffer. Make sure that your worker thread that does the ::PostMessage is ensuring that the message is successfully posted.
Chris Meech I am Canadian. [heard in a local bar] In theory there is no difference between theory and practice. In practice there is. [Yogi Berra] posting about Crystal Reports here is like discussing gay marriage on a catholic church’s website.[Nishant Sivakumar]
yes I verified that. I wonder how other UI applications work fine when they have to draw a lot of things. For example a video player where it plays hundreds of frames in each second.
-
Thanks all, Here is my answers: It a share-market application which receives heavy broadcast from the server. I have a worker thread for receiving the data. After receiving the data, this thread formats data into structures and sends to another worker thread for processing. After processing that; thread posts a message (using ::PostMessage) to the active view to display the data. That view is only handling the display of the data but as the data is more it takes some time (200 milliseconds) to display. View is setting that data into a grid (UltimateGrid). Broadcast packet comes in every 500 milliseconds. Each packet contains data to be filled in approx 80 rows of the grids ( 80 * 9 cells). There is also color formatting and bold fonts on some cells. This all eats up 15 to 20% of the CPU. It freezes when I moves a child window over the grid while it was actually drawing the data on it. Just Because view was busy with handling the POSTMessages sent by broadcast thread. If I move the code which sets the grid cells, into any other worker thread then CPU utilization goes below 5% and view does not freeze but grid crashes when I scroll the grid, because internally it tries to copy the data from one row to another row however there is only one thread which updates the grid. Even though I also tried for synchronization in grid methods but that did not worked so now I am hanging between whether I should do cell setting on view (everything works fine but view freezes) or inside some worker thread (grid crashes but nothing freezes). Is there any further optimization?
Hmm, if you really need data every .5 seconds, so much data that it takes .2 seconds to render it, then can you either cute down the frequency of data arriving at the screen? After all, it is for human eye ball consumption, does it really need .5 second updates? Or, can you move the entire data display object into a seperate thread from the main window? I dont know, never tried it, but it might work.
============================== Nothing to say.
-
Thanks all, Here is my answers: It a share-market application which receives heavy broadcast from the server. I have a worker thread for receiving the data. After receiving the data, this thread formats data into structures and sends to another worker thread for processing. After processing that; thread posts a message (using ::PostMessage) to the active view to display the data. That view is only handling the display of the data but as the data is more it takes some time (200 milliseconds) to display. View is setting that data into a grid (UltimateGrid). Broadcast packet comes in every 500 milliseconds. Each packet contains data to be filled in approx 80 rows of the grids ( 80 * 9 cells). There is also color formatting and bold fonts on some cells. This all eats up 15 to 20% of the CPU. It freezes when I moves a child window over the grid while it was actually drawing the data on it. Just Because view was busy with handling the POSTMessages sent by broadcast thread. If I move the code which sets the grid cells, into any other worker thread then CPU utilization goes below 5% and view does not freeze but grid crashes when I scroll the grid, because internally it tries to copy the data from one row to another row however there is only one thread which updates the grid. Even though I also tried for synchronization in grid methods but that did not worked so now I am hanging between whether I should do cell setting on view (everything works fine but view freezes) or inside some worker thread (grid crashes but nothing freezes). Is there any further optimization?
I was thinking about answering with some ideas but then I stopped. I need to know something more basic first. If the output in the grid control is 80 rows and the user can scroll (you said that caused issues before) then my question has to do with the presentation of the data. Where does "new data" show up in the grid? At the bottom? At the top? How big is that control? 80 rows should take up quite a bit of vertical real estate. What is the user scrolling through? By that I mean, when they scroll, are they looking to see older data? What happens to the newer data when the scroll causes it to be out of view? I think that your idea to move the updates to the processing thread (or other) but not the GUI (using PostMessage()) is the right idea. It clearly has less overhead than clanking through the windows messaging system. Use the windows messages for things like redraw (Paint) or click events and not presenting new data. But the conflict with the user scrolling got me worrying about what the user is scrolling through. What is the users expectation of what they will see when scrolling through an application that continuiously presents new data? I think that's the area where you have to think about what it means and how you want to handle the responsiveness to scrolling.
-
Hmm, if you really need data every .5 seconds, so much data that it takes .2 seconds to render it, then can you either cute down the frequency of data arriving at the screen? After all, it is for human eye ball consumption, does it really need .5 second updates? Or, can you move the entire data display object into a seperate thread from the main window? I dont know, never tried it, but it might work.
============================== Nothing to say.
yeah, that's what I was thinking until I read that the user can scroll through the data. Depending on what "scrolling through the data" means, he may have to retain all the data, even if it flashed by too fast for the user to see, they may want to go back and look at it using "scroll".
-
yes I verified that. I wonder how other UI applications work fine when they have to draw a lot of things. For example a video player where it plays hundreds of frames in each second.
Most application avoid using the message queueing system but rely on some other mechanism to tell them when to render data. Once you are in a steady state running a video or receiving data and displaying it, you really don't need to messaging system except for keeping the display pretty (like repaint when uncovered) or handling user inputs like a cancel button or the scroll bar.
-
I was thinking about answering with some ideas but then I stopped. I need to know something more basic first. If the output in the grid control is 80 rows and the user can scroll (you said that caused issues before) then my question has to do with the presentation of the data. Where does "new data" show up in the grid? At the bottom? At the top? How big is that control? 80 rows should take up quite a bit of vertical real estate. What is the user scrolling through? By that I mean, when they scroll, are they looking to see older data? What happens to the newer data when the scroll causes it to be out of view? I think that your idea to move the updates to the processing thread (or other) but not the GUI (using PostMessage()) is the right idea. It clearly has less overhead than clanking through the windows messaging system. Use the windows messages for things like redraw (Paint) or click events and not presenting new data. But the conflict with the user scrolling got me worrying about what the user is scrolling through. What is the users expectation of what they will see when scrolling through an application that continuiously presents new data? I think that's the area where you have to think about what it means and how you want to handle the responsiveness to scrolling.
Actually each row has a "trading-share or stock-share" in it so when data comes from servers I have to update the rows containing the old data. As there are thousands of share available in market, user can have hundreds of share in market watch grid to keep an eye with their prices and other details. As there may be 80 or more rows but the visible are can show only 60 rows so to see remaining he has to scroll down. It's not like chatting application where first row is the oldest row and bottom row is the newest row. Each row has a "stock name" and when it's update comes I have to update it.Currently I am planning to reduce the refresh rate and doing a batch update of multiple rows.
-
Actually each row has a "trading-share or stock-share" in it so when data comes from servers I have to update the rows containing the old data. As there are thousands of share available in market, user can have hundreds of share in market watch grid to keep an eye with their prices and other details. As there may be 80 or more rows but the visible are can show only 60 rows so to see remaining he has to scroll down. It's not like chatting application where first row is the oldest row and bottom row is the newest row. Each row has a "stock name" and when it's update comes I have to update it.Currently I am planning to reduce the refresh rate and doing a batch update of multiple rows.
Well, if that's the case then the interlock between the scroll and the update should be relatively easy to manage. The thread that is doing the updates (assuming you move the update code out of the message loop) grabs a "lock" (an EVENT) before updating the cells and releases it when it's finished. The "scroll" message processing grabs the same "lock" before processing the scroll and releases it after. Neither should collide. I assume you have worked out the issues with having a stock symbols location moving between any two bursts of input data due to scrolling as you do have scrolling working at all. So, as I said in a previous post, it would seem to be better to process and update the control in one process away from the GUI message loop, something you've tried before and saw a performance improvement (reduced cpu usage) and probably enhanced responsiveness to the updates.
-
Actually each row has a "trading-share or stock-share" in it so when data comes from servers I have to update the rows containing the old data. As there are thousands of share available in market, user can have hundreds of share in market watch grid to keep an eye with their prices and other details. As there may be 80 or more rows but the visible are can show only 60 rows so to see remaining he has to scroll down. It's not like chatting application where first row is the oldest row and bottom row is the newest row. Each row has a "stock name" and when it's update comes I have to update it.Currently I am planning to reduce the refresh rate and doing a batch update of multiple rows.
If the visible part of the control only represents some of the data, then can you maintain a sort of database of data, updated every .5 seconds, but only display a small part of the data at a time, depending of course on the scroll position?
============================== Nothing to say.
-
Thanks all, Here is my answers: It a share-market application which receives heavy broadcast from the server. I have a worker thread for receiving the data. After receiving the data, this thread formats data into structures and sends to another worker thread for processing. After processing that; thread posts a message (using ::PostMessage) to the active view to display the data. That view is only handling the display of the data but as the data is more it takes some time (200 milliseconds) to display. View is setting that data into a grid (UltimateGrid). Broadcast packet comes in every 500 milliseconds. Each packet contains data to be filled in approx 80 rows of the grids ( 80 * 9 cells). There is also color formatting and bold fonts on some cells. This all eats up 15 to 20% of the CPU. It freezes when I moves a child window over the grid while it was actually drawing the data on it. Just Because view was busy with handling the POSTMessages sent by broadcast thread. If I move the code which sets the grid cells, into any other worker thread then CPU utilization goes below 5% and view does not freeze but grid crashes when I scroll the grid, because internally it tries to copy the data from one row to another row however there is only one thread which updates the grid. Even though I also tried for synchronization in grid methods but that did not worked so now I am hanging between whether I should do cell setting on view (everything works fine but view freezes) or inside some worker thread (grid crashes but nothing freezes). Is there any further optimization?
As a possible step to improve performance, have you tried using LockWindowUpdate on the control while you are adding the new data to it, and then calling UnlockWindowUpdate after? This stops the control trying to redraw itself on each event that modifies its content. Untill all the modifications have been done.
If you vote me down, my score will only get lower
-
As a possible step to improve performance, have you tried using LockWindowUpdate on the control while you are adding the new data to it, and then calling UnlockWindowUpdate after? This stops the control trying to redraw itself on each event that modifies its content. Untill all the modifications have been done.
If you vote me down, my score will only get lower