Problem with XP scheduler?
in [Win32 Kernel]
|
From: Hector Santos on 13 Jan 2010 21:25 tanix wrote: > In article <6eeaedac-8828-4b85-9c0e-7a49bc3dec28(a)m26g2000yqb.googlegroups.com>, Leo Davidson <leonudeldavidson(a)googlemail.com> wrote: >> On Jan 13, 8:40=A0pm, "Paul Baker [MVP, Windows Desktop Experience]" >> <paulrichardba...(a)community.nospam> wrote: >>> Agreed. I have seen a handful of cases ever in which the entire desktop >>> repaints, apparently unecessarily. In all such cases, I can tell by the w= >> ay >> >> I've seen desktop repaints caused by two things (though there may be >> more, of course): >> >> 1) Code that (almost always accidentally) calls InvalidateRect on a >> NULL window handle, which causes the whole screen to repaint. >> Discussion of that is here: >> >> http://blogs.msdn.com/oldnewthing/archive/2006/03/07/545295.aspx >> >> 2) Something explicitly clearing the shell icon-cache or telling the >> shell that the file types / icons have changed, so that it has to re- >> fetch all the icons and repaint them. Usually done on purpose after a >> program takes over a file type. > > And, no matter what is the "reason", it is TOTALLY inappropriate, > totally unnecessary, and "not nice" if you are working on something, > and ESPECIALLY when you click on something expecting something else > to happen. And, all of a sudde, boom! > > I could accept THIS kind of boom about a generation ago. > But not in this day and age. Personally, just an opinion, if this was happening to me at the level you describe where it becomes annoying, then I would suspect some form of machine interrupt issue, i.e. its an hardware issue. It is important to have a decent graphic card for windows and of course, decent RAM and proper paging setup for the machine. One test I give customers to get an overall feel to see if the machine and OS have a memory loading issue, is to see what the Memory Load factor is. I display it in our application server status screen. Its a simple function call: #include <stdio.h> #include <windows.h> void main(char argc, char *argv[]) { MEMORYSTATUS ms; ms.dwLength = sizeof(ms); GlobalMemoryStatus(&ms); printf("Memory Load: %d%%",ms.dwMemoryLoad); } The lower the better. The higher it is, the "harder" the OS is working to load your system applications memory requirements. I recall customers who had high memory loads like 50% or higher and a simple change in their graphic cards or extra ram lowered the value down to 0%, 5%, 10%. To me, the graphic card is as much important as anything else because, well, its your VIDEO :) -- HLS
From: Alexander Grigoriev on 13 Jan 2010 22:17 I think explorer doesn't keep the icons preloaded. Every time it needs to redraw the desktop, it scans the desktop folder and reads all the icons. If the files fell out of cache, that will cause disk access. Win9x used to have shell icon cache file, but it was getting corrupted often, supposedly because of lack of proper synchronization in the code. "Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message news:e11KsmHlKHA.5604(a)TK2MSFTNGP04.phx.gbl... > Paul Baker [MVP, Windows Desktop Experience] wrote: > >> I don't think you're talking about the screen buffer. I think you're >> talking about the desktop window being invalidated and therefore >> receiving a WM_PAINT message, and possibly a WM_ERASEBKGND message. Then >> it has to redraw itself. I have never seen this happen when you click the >> "+" in the folders pane in Windows Explorer. Certainly, it is not the >> usual case. There is some other condition causing it, almost certainly >> unrelated to the OS. > > > Well, I don't recall if its the "+" but I must admit I have seen many > times where "out of the blue" for some apparent reason, there is a desktop > refresh where all the desktop ICON go blank and and refresh themselves. > It can be 1 to 2 seconds and yes, at times, it appears to take a lot > longer and everything stops until it is finished. > > Why? > > I have my ideas of course, but I have not spent the time to pin-point it > down to any particular action. I'm not defending or condone the direction > this thread has taken, but no doubt, it happens and you can't help but > have that momentary thought to wonder what you just do or what did the > system do that cause it. If any thought was put into it, was the idea > that Windows is just getting more overhead, doing more and it when it > comes to refreshing the desktop, there is some contention somewhere that > slows it down. I will say that after upgrading to XP SP3 in the last week > of December, I thought I noticed things were slower but it appears to be > ok "back to normal" again. I am one that don't like anything slow. > > I should note, I have 50% or more of my desktop filled with ICONS :) And I > pretty good/fast (not cheap) graphic cards. > > -- > HLS
From: tanix on 14 Jan 2010 02:05 In article <OS447DLlKHA.3832(a)TK2MSFTNGP04.phx.gbl>, Hector Santos <sant9442(a)nospam.gmail.com> wrote: >tanix wrote: > >> In article <#gQQWIJlKHA.2188(a)TK2MSFTNGP04.phx.gbl>, "Paul Baker [MVP, Windows > Desktop Experience]" <paulrichardbaker(a)community.nospam> wrote: >>> Tanix, >>> >>> When you say "SendMessage bypasses the message queue", it is true that the >>> message is not added to the message queue, but I did quote documentation >>> that explains a relationship between SendMessage and the message queue, so >>> be careful. >> >> I asked you specifically: what is the difference between >> SendMessage and PostMessage. >> >> Can you please tell me? > >If this will help, in principle, > > SendMessage() is Synchronous, PostMessage() is Asynchronous. Correct, and that is the whole argument. >Synchronous means it won't return until a answer is returned. >Asynchronous means, "do it", send the message, don't wait and comes >back immediately. This is very important in Windows because the >message queue is the main thread and it is still a multi-tasking >framework (within the main thread). > >Overall, the SendMessage() goes directly to the proc that is handling >messages for it. It is a SYNCHRONOUS call and the caller is BLOCKED >until the receiver (the proc) returns an answer. Correct. And that is EXACLY the reason you don't want to use it as a matter of practice. No one prohibits you from using it, but not as a general practice. >PostMessage() will >add it to the main thread message queue and return immediately >(ASYNCHRONOUS) where the main thread message handler is reading and >processing all the messages posted into the queue. Correct. And that is EXACTLY what your code should be doing in vast majority of situations. >What that means is that if you are using non-main threads, using Send >vs Post is important in how things behave and perform. You generally >want to POST to the main thread from secondary threads because the >function returns immediately. Correct. > It is normally not a good design to use >SendMessage() from a thread unless you have specific and complex >synchronization design needs in this area and generally, there are >other functions to use here instead of SendMessage(). Precisely. Basically, all the places in your code that rely on SendMessage need to be reexamined. Most likely your desing is wrong. And that is exactly the argument here. -- Programmer's Goldmine collections: http://preciseinfo.org Tens of thousands of code examples and expert discussions on C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript, PHP, organized by major topics of language, tools, methods, techniques.
From: tanix on 14 Jan 2010 02:14 In article <OlI#ogMlKHA.5020(a)TK2MSFTNGP02.phx.gbl>, "Alexander Grigoriev" <alegr(a)earthlink.net> wrote: >I think explorer doesn't keep the icons preloaded. Every time it needs to >redraw the desktop, it scans the desktop folder and reads all the icons. If >the files fell out of cache, that will cause disk access. Win9x used to have >shell icon cache file, but it was getting corrupted often, supposedly >because of lack of proper synchronization in the code. The point is that desktop needs to be managed by the OS. No matter what some app does, it should not affect the OS managed things, such as desktop. I have no clue which "evil" apps I have, but I do see these desktop redraws quite a bit and that happens not when I am running some program, but when I am using the OS related programs such as explorer. No matter what I do in ANY of my explorer windows, and I typically have 4 to 6 of them opened at the same time so I can quickly move things around and open files in those directories, it should NOT cause the entire desktop redrawing. And I bet MS knows about this situation for years. But, for some strange reason, it is not getting fixed, which means to me that this issue is so fundamental, that they can not even fix it, no matter what they do. Which, in turn means, there are some scheduling issues that cause the events to get routed to the wrong client in some cases. I can not speak for MS. The OS guys can shed some light on it. But I really do not appreciate THIS kind of thing happening to me, especially when I deal with operations that may produce hundreds of thousands of files and modify my major archives or move things around to the places I do not even know. Because I do not know what exact event was mishandled. >"Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message >news:e11KsmHlKHA.5604(a)TK2MSFTNGP04.phx.gbl... >> Paul Baker [MVP, Windows Desktop Experience] wrote: >> >>> I don't think you're talking about the screen buffer. I think you're >>> talking about the desktop window being invalidated and therefore >>> receiving a WM_PAINT message, and possibly a WM_ERASEBKGND message. Then >>> it has to redraw itself. I have never seen this happen when you click the >>> "+" in the folders pane in Windows Explorer. Certainly, it is not the >>> usual case. There is some other condition causing it, almost certainly >>> unrelated to the OS. >> >> >> Well, I don't recall if its the "+" but I must admit I have seen many >> times where "out of the blue" for some apparent reason, there is a desktop >> refresh where all the desktop ICON go blank and and refresh themselves. >> It can be 1 to 2 seconds and yes, at times, it appears to take a lot >> longer and everything stops until it is finished. >> >> Why? >> >> I have my ideas of course, but I have not spent the time to pin-point it >> down to any particular action. I'm not defending or condone the direction >> this thread has taken, but no doubt, it happens and you can't help but >> have that momentary thought to wonder what you just do or what did the >> system do that cause it. If any thought was put into it, was the idea >> that Windows is just getting more overhead, doing more and it when it >> comes to refreshing the desktop, there is some contention somewhere that >> slows it down. I will say that after upgrading to XP SP3 in the last week >> of December, I thought I noticed things were slower but it appears to be >> ok "back to normal" again. I am one that don't like anything slow. >> >> I should note, I have 50% or more of my desktop filled with ICONS :) And I >> pretty good/fast (not cheap) graphic cards. >> >> -- >> HLS > > -- Programmer's Goldmine collections: http://preciseinfo.org Tens of thousands of code examples and expert discussions on C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript, PHP, organized by major topics of language, tools, methods, techniques.
From: Hector Santos on 14 Jan 2010 03:31
tanix wrote: > No matter what I do in ANY of my explorer windows, and I typically > have 4 to 6 of them opened at the same time so I can quickly move > things around and open files in those directories, > it should NOT cause the entire desktop redrawing. Explorer is just another application. Try replacing it with something else at least to compare. I've seen clones out there. > And I bet MS knows about this situation for years. > But, for some strange reason, it is not getting fixed, > which means to me that this issue is so fundamental, that they > can not even fix it, no matter what they do. Tanix. I still say that you might have something going on in your system. Why? Precisely for the reason you stated - its so fundamental there would be millions of reports. No one would like to see their system behave as you describe. No one, and IMO, this would not be something MS would ignore. But I have not seen or heard of the severe annoying level you are describing. Therefore IMO, I think it is machine related or you have some explorer registered hook that is interfering. I recall several years back I found an interested DLL hook at CodeProject that registered a hook into explorer. If I remember, it allowed you to see the REGISTRY in the Explorer window. I don't recall if it did things with the DESKTOP ICONS but it was so annoying and it was differently changing the behavior of system, slow if I remember that I had to get rid of it. It was hard to remove but finally did. -- HLS |