Home > Software engineering >  Is there any way to speed up the MFC LISTCTRL display and filling
Is there any way to speed up the MFC LISTCTRL display and filling

Time:10-03

Everybody is good, I in the use of VC in a PC data analytical software, PC using LIBUSB to receive the next bit machine transmission of data, I read a thread in the LIBUSB analytical data, the data has the fixed format pass a frame frame, parsed fills the LISTCTR inside, I'll take these data LISTCTRL first column is the variable names, there are about 30 variables, followed by the contents of the variable and variable content from time to time to refresh, fill the data item is done with m_listctrl. SetItemText () for filling out this function, now found in my notebook when frame rate of more than 800, the entire program is very slow, some frames have shown no, on the desktop frame rate of more than 1400, programs are slow, click on the BUTTON on some of the program takes a long time to come, at this point in the task manager to see the program's CPU occupancy rate has reached thirty percent, basically I also tried LISTCTRL virtual list, improvement is not obvious, the feeling is refresh fast, LISTCTRL filling cost a lot of time, don't know if you the great god of BBS have better method to deal with this problem, the key is how to make LISTCTRL filling time shorter, or is there any other better control to deal with this problem?

CodePudding user response:

If you are in the thread directly transferred
M_listctrl. SetItemText ()
Want to be no good BuKa, because you did not leave time for response to other messages.
Threadfunction
{
Sleep (10);//must sleep yourself, equinoctial time slice to the main thread;

}

And there is a problem, m_listctrl insert so much data, in fact users only see part of the data, that is to say, you can actually save the received data, such as the user to display a page, when going through without the insert 1400, is a bit scary, but also bad experience,

To 28 * 14 * 100 or 50 is not better? Show only the part of every time

CodePudding user response:

If a large amount of data, you should not be all show, paging, etc., of data update only one page at a time, to reduce the loss of performance

CodePudding user response:

Actually the list altogether has more than 30 lines, can all display a page, each line only data constantly change, I want these real-time observation data, it is not to the paging view, I'm filling in the LIBUSB read threads, just the LIBUSB continuously collect data, otherwise LIBUSB can read threads should be blocked, feel like tajon1226 said, if the delay 10 ms, I'm afraid I will be more poor real-time performance, don't know if I understand right?

CodePudding user response:

1 do cache data, comparison before and after update. If the same would skip
2 time snapshot refresh, high refresh rate for human eyes does not make sense

CodePudding user response:

M_list. SetRedraw (FALSE);
//add content
XXXX
//update content
M_list. SetRedraw (TRUE);

CodePudding user response:

Refresh fast doesn't make sense, all the data collect, the notification window from memory refresh ListCtrl

CodePudding user response:

This is not what acceleration is not problem,
Should open another thread is dedicated to the receiving data, the main thread is used to display data, only by this way, want to is difficult
  • Related