|
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
|
|
|
|
|
Wow. That's a great tip. Thanks for sharing!
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Hello,
Does someone tried to recompile the class CSimpleDate with visual studio 2010 without error?
Is there an equivalent class for managing dates and compile under Visual Studio 2010?
|
|
|
|
|
|
xylo wrote: Does someone tried to recompile the class CSimpleDate with visual studio 2010 without error?
You might ask the author, since it was initially created with VS6.
"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'm such a good boy)
it compiles ok when you fix the 2, 3 _very_ simple compilation errors (VC6 was a crappy compiler); and fix the unsafe functions (I did not fix them).
The project crashes because there are memory overruns (could be fixed by replacing unsafe functions with their safe variants.
Watched code never compiles.
|
|
|
|