|
Good point. I was thinking "Overloaded" in the OOP sense and not in the "too much work to do in the time alloted" / "too busy" sense.
Is it time to argue about MessagePeek loops again? 
|
|
|
|
|
Chuck O'Toole wrote: Is it time to argue about MessagePeek loops again?
Well, as I said to the guy a few weeks back, the correct design is to put the work and waits into threads to leave the message processing unaffected. Anything else is a hack. 
==============================
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'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.
|
|
|
|
|
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.
|
|
|
|
|
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".
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
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
|
|
|
|
|
Good tip.
==============================
Nothing to say.
|
|
|
|
|
I have a very small form on to a property page. If the user have not save the modification, I want to prevent closing property page ... but I can't do that.
Here is the code where I start the property page :
CTestSheet PropertySheet(_T("Test"),NULL,0);
PropertySheet.m_psh.dwFlags |= PSH_NOAPPLYNOW;
PropertySheet.AddPage(new CTestPage);
PropertySheet.DoModal();
delete PropertySheet.GetPage(0);
and I override OnClose handler in property page, in property sheet, I override OnDestroy in property sheet ... in vain ... doesn't function ... why ?
|
|
|
|
|
The Big [X] or system menu (in the icon) of Close (Alt+F4) comes in through "ON_WM_SYSCOMMAND". In your processing look for "SC_CLOSE". If you don't have one, you'll need to add
ON_WM_SYSCOMMAND() to your Message Map.
void YourClass::OnSysCommand(UINT nID, LPARAM lParam)
{
if ((nID & 0xFFF0) == SC_CLOSE)
{
}
}
Once you've seen the SC_CLOSE message, you can check with the PropertyPages to see if it is OK to proceed or to popup a message about saving data.
|
|
|
|
|
Flaviu2 wrote: If the user have not save the modification, I want to prevent closing property page ... but I can't do that.
Have you considered calling the page's SetModified() method, overriding the page's OnKillActive() method, or handling the TCN_SELCHANGING notification?
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
|
|
|
|
|
I solve the problem, overriding OnKillActive event. Thank you very much !
|
|
|
|
|
Hi all,
i am playing a video in my application using directx.
i have made a dialog based application and on that i have put a static control in which i am showing video.
My problem is after playing my video when i minimize my window my static control becomes empty. And if i again move the window the video starts displaying again i.e. there is problem in refreshing.
But i am not getting how to resolve it?
Can anybody please help me in this??
thanks in advance
|
|
|
|
|
Just a quick guess: try toggling the 'clip children' style of the hosting dialog.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> If it doesn't matter, it's antimatter.<
|
|
|
|
|
I'm writing some port forwarding code and don't have control over the size of the data being sent/received. So I need to always have a recv queued even though I may possible be in the middle of a write (since my overlapped sockets are reading and writing to and from each other whenever recv gets new data on either side).
How do I allow for the possibility that an unblocked worker thread could be processing a read or a write? IOW how do I know if GetQueuedCompletionStatus was unblocked for a pending WSARecv or WSASend?
thanks.
---jt
modified 16-Nov-11 15:47pm.
|
|
|
|
|
I would do it by using separate event handles for the read and the write, and then inspecting the return value from your wait function to see which event handle was signaled.
EDIT ==========
OK, I see what you're doing. You're polling GetQueuedCompletionStatus, right? Well that's not the optimum model to use with completion ports, as you see.
You're much better off using the OVERLAPPED structure when you call WSARecv and WSASend, and then seeing which event handle is signaled.
Here's the pseudo code:
ORecv = new OVERLAPPED struct;
Set ORecv's event handle to your Recv event;
call WSARecv with ORecv;
OSend = new OVERLAPPED struct;
Set OSend's event handle to your Send event;
call WSASend with OSend;
Wait on the two handles;
See which handle was signalled,
and then call GetQueuedCompletionStatus;
The difficult we do right away...
...the impossible takes slightly longer.
modified 16-Nov-11 16:45pm.
|
|
|
|
|
Thanks. I'm not polling, I am using the overlapped structure in send and recv but hadn't thought to use separate structures for send versus recv. That should work...thanks.
|
|
|
|
|
I personally don't like the idea of waiting on OVERLAPPED handles. I'd much rather not introduce more (or any) synchronization objects to the IOCP handler threads but instead let the IOCP do its magic with all threads waiting on GetQueuedCompletionStatus.
I take advantage of the fact that the same overlapped structure pointer you pass to an overlapped function will be returned to you so I use extended OVERLAPPED structures like the one in this article[^]
typedef struct _OVERLAPPEDPLUS {
OVERLAPPED ol;
SOCKET s, sclient;
int OpCode;
WSABUF wbuf;
DWORD dwBytes, dwFlags;
} OVERLAPPEDPLUS;
The opcode can be used to indicate read or write (and many other things including non-I/O tasks you
want to queue on the IOCP). Also gives you a handy place to keep buffers associated with the operation.
Mark Salsbery
![Java | [Coffee]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/coffee.gif)
|
|
|
|
|
Wow. That's a great tip. Thanks for sharing!
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
