Problem with XP scheduler?
in [Win32 Kernel]
|
From: Leo Davidson on 13 Jan 2010 17:19 On Jan 13, 8:40 pm, "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 way 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.
From: tanix on 13 Jan 2010 18:23 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. -- 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 13 Jan 2010 18:24 In article <#gQQWIJlKHA.2188(a)TK2MSFTNGP04.phx.gbl>, "Paul Baker [MVP, Windows Desktop Experience]" <paulrichardbaker(a)community.nospam> wrote: > >Tanix, > >Forgive me if this post seems out of context. I don't want to quote pages >and pages of information that we have all seen in previous posts. It can >just get a little silly after a while. > >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? Sorry, I can not spend more time on this. Enough. >The new information I see here is "I do not have these kinds of problems >with Java, which is my preferred language for quite a while now". I really >am not trying to be antagonistic here, but you make it very difficult not to >be. I can't help but to point out that if your preferred language is Java, >which is designed to be platform independant, and you're not writing native >code, then how do you expect to have a good enough understanding on OS >internals to carry on a debate about it and, more than that, disagree >strongly with several experts I believe to be correct. Also, Java is not an >OS. It's dependant on the a virtual machine running on the OS. Windows is >still in play here. It's as if you're saying "If I use Windows, I have a >problem but if I use Windows, I do not". So the fact that you do not see a >problem when using Java could be explained by a defect in your Java >application that masks these "problems", which are actually not problems at >all but rather intended and reasonable behaviour, as explained by others. > >Paul > > -- 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 13 Jan 2010 19:31 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. 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. 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. 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. 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(). -- HLS
From: Hector Santos on 13 Jan 2010 21:13
Leo Davidson wrote: > On Jan 13, 8:40 pm, "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 way > > I've seen desktop repaints caused by two things (though there may be > more, of course): > > 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. Interesting Leo. Thanks for the input. #2 seems to be very plausible in my development machine where I have many browsers installed for testing. I purposely make sure they don't try to take over and become the default browser, but who knows what some of these are doing in their "on-going strategic" to "hook" into everything you do. Also, if any ICON is linked to a non-local machine resource, that could be another reason. -- HLS |