[fix]Very slow buttons on Win10 Fall CreatorUpdate
Printed From: Codejock Forums
Category: Codejock Products
Forum Name: Toolkit Pro
Forum Description: Topics Related to Codejock Toolkit Pro
URL: http://forum.codejock.com/forum_posts.asp?TID=23487
Printed Date: 24 November 2024 at 5:22am
Software Version: Web Wiz Forums 12.04 - http://www.webwizforums.com
Topic: [fix]Very slow buttons on Win10 Fall CreatorUpdate
Posted By: rdhd
Subject: [fix]Very slow buttons on Win10 Fall CreatorUpdate
Date Posted: 14 November 2017 at 9:31am
|
Heads up! We have customers that are getting the latest Win 10 update. Something named "Fall creator update". They are then reporting that after working a while the software is slowing down dramatically when displaying dialogs or anything (it turns out) with buttons on it. We put it on a box and sure enough, displays can get so bad you can watch the UI display, control-by-control! We have found that calls to the GDI GetPixel API are what is slowing down the display. We have been using the CXTButton::SetTheme(xtThemeOfficeXP) and in the theme drawing code we encountered (discovered via profiling) GetPixel being very slow. So we changed to use the xtThemeOffice2010 theme to get performance back with those buttons as GetPixel isn't in the theme drawing code paths for CXTButton. Now we are scrambling to find and eliminate calls to GetPixel in our code and trying to avoid any CJ code that also calls GetPixel. For our code, I have changed to DIBs to avoid any GetPixel calls and that avoids the performance penalty. I did contact Microsoft regarding this issue. The reply was they would see if anyone else is complaining (haven't heard back yet). In the meantime, we are eliminating calls to GetPixel with extreme prejudice. |
Replies:
Posted By: Marco1
Date Posted: 16 November 2017 at 4:23am
|
Interesting... Apart from that, GDI Get/Set Pixel API has and had always been painfully slow. Seems it's getting worse... Using DIBs is the right way, so far. ------------- Product: XTP 18.3.0 on VS 2017 Platform: VS 2017 / Windows 10 (64bit) |
Posted By: rdhd
Date Posted: 16 November 2017 at 9:01am
|
I used the MFC app wizard in Visual Studio to create an app that shows the issue. MS now has the app and has indicated they see the issue when running it. Hopefully there will be a fix from MS but right now there is no indication of a time frame. |
Posted By: SDGUY
Date Posted: 29 November 2017 at 10:47am
| Anyone heard any update on this? We use an app that uses CodeJock to display buttons in a ribbon and it is now painfully slow 7+ seconds to load ribbon |
Posted By: rdhd
Date Posted: 04 December 2017 at 5:51pm
|
I was told by a Microsoft support engineer that for FCU, the issue was due to a change in underlying memory allocation code. Some customers say this gets bad/worse with time. So that might mean it is a memory issue. However, we have had complaints saying our app is "sluggish" on Win 10 RTM (I think it was 1609) and the support engineer said that the memory allocation change isn't in that version. Microsoft has not yet put a time frame on a fix. But the engineer asked me to fill out a form asking for a hot fix. Apparently, the next update isn't due until April so a hot fix is highly desirable. I expect an update on the situation soon. In the meantime, I have eliminated all critical (frequently used) code paths to GetPixel and hope it is the only affected API. I don't know if the memory allocation change is specific to GetPixel or not. |
Posted By: SDGUY
Date Posted: 04 December 2017 at 5:52pm
|
can you let me know if you get a hotfix? Maybe it will assist us too! Thanks rdhd
|
Posted By: rdhd
Date Posted: 05 December 2017 at 10:47am
|
Sure thing. |
Posted By: franji1
Date Posted: 11 December 2017 at 4:14pm
|
We are seeing it on XTP 13 with the following themes: Fancy, Icy, Modern, Office 2003, Office XP, Visual Studio, Windows XP These behave OK: Beveled, Gnome, Gradient, Gray, Mac, Office 2000
|
Posted By: franji1
Date Posted: 13 December 2017 at 5:26pm
|
At least for me (XTP 13), it appears that Microsoft fixed it in their latest hot fix: December, 2017 – Cumulative Update for Windows 10 Version 1709 for x64-based Systems KB4054517 OS Build 16299.125 FYI, we have a different product that uses XTP v15 and it did NOT have this issue.
|
Posted By: rdhd
Date Posted: 13 December 2017 at 5:55pm
|
The KB doesn't mention any fix to the GDI memory allocator. Still, perhaps the fix is in. I sent mail to our MS support contact but got the out-of-office reply. |
Posted By: franji1
Date Posted: 13 December 2017 at 5:58pm
I saw that too (or did not see that too). When it says "Cumulative Update", if I missed an earlier "hot fix" for 1709/16299, could it be documented in a previous KB???
|
rdhd wrote:Posted By: franji1
Date Posted: 13 December 2017 at 6:08pm
|
Here's a screen shot of our application we are currently working on. It was taking 10 to 14 seconds to load the frame in the previous FCU (no opened document). With this hot fix, it's less than a second (as expected). Menus pop also, like they should.  |
Posted By: franji1
Date Posted: 13 December 2017 at 6:11pm
|
Here's what it looked like when it "hung" for 10+ seconds (customers would NOT like this):  |
Posted By: rdhd
Date Posted: 14 December 2017 at 8:46am
|
Microsoft says the fix is NOT in yet. It will be in the next OS and might be made available (no warranty) in an insider's update. |
Posted By: rdhd
Date Posted: 14 December 2017 at 8:47am
|
At least some of our customers say applying the fix makes no difference. |
Posted By: franji1
Date Posted: 14 December 2017 at 9:10am
|
We've been using XTP V13 since 2012 in this product, and all our versions mis-behaved after I upgraded to FCU of Win10 a few weeks ago. When I applied the KB patch from MS mentioned above, they ALL work as expected. A co-worker has experienced the same issue and the same KB update fixed him also (we both have the same PC). If it might have been a video driver anomaly, I checked the event log of my video driver (AMD Radeon HD 70900 series). It showed that an update occurred on Nov 17th, which is probably when I upgraded to FCU. However, no driver updates have occurred since then. So did that driver cause my problem? But then how did the problem go away on my PC? (I don't expect any answers, just thinking out loud). :-\ EDIT: STILL AN ISSSUE - SEE MY LATER POSTS (W10FCU KB UPDATE CAUSED REBOOT, WHICH CLEARED FRAGMENTED GDI HEAP, SO JUST A MATTER OF TIME BEFORE ISSUE SHOWED ITS UGLY HEAD)
|
Posted By: rdhd
Date Posted: 14 December 2017 at 10:28am
|
Customers say that once things slow down, rebooting fixes the issue for a while. That makes sense since MS says the problems we are having with GetPixel are due to a low level GDI memory allocation change. MS says GetPixel exacerbates the problem as they are allocating memory for one pixel at a time. My guess is that memory may be getting fragmented over time as it sounded like calling GetPixel in a loop used to result in the same memory being allocated, freed and allocated but is now getting new memory for each call. So perhaps a reboot helped? Or the GetPixel call isn't the root of your issues. When you are frozen, do you debug break and find yourself in the low level get pixel code? |
Posted By: franji1
Date Posted: 14 December 2017 at 10:50am
Since it is "fixed", this is not as simple to do. However, if I find the time, I could roll back and possibly duplicate the problem and do what you said.
|
Posted By: franji1
Date Posted: 14 December 2017 at 11:02am
| I think the memory fragmentation is the cause. We are seeing the load of our app getting "slower". |
Posted By: astoyan
Date Posted: 14 December 2017 at 4:21pm
|
The problem is indeed with the Fall Creators Update. After investigating it it's turned out the Magnifier is the one to blame for performance issue. Even if you don't use it it is still responsible. As a simple manual workaround just disable bitmap smoothing in its options. Unfortunately so far there is no known method for disabling it for a specific application. It is also a known issue to Microsoft already, hopefully they will address it soon. Regards, Alexander  |
Posted By: rdhd
Date Posted: 14 December 2017 at 4:29pm
|
Alexander, I have an open case with MS. I am being told the problem is a low level GDI memory allocator code change in FCU. GetPixel is not the only affected API but it definitely exacerbates the issue due to it constantly allocating memory for a single pixel. There is no "work around" that will solve that issue. I suspect Magnifier is just like many other programs in that it too is making lots of calls to GetPixel. Microsoft has a fix for the next release. They might make it available for people in the insiders program. I have filed out the necessary forms to request a hot fix. I asked again today if the hot fix will be made available (no reply yet.) |
Posted By: franji1
Date Posted: 18 December 2017 at 3:24pm
Yes. Here's my stack dump when I hit "pause" in VS - and it is in CDC::GetPixel in the middle of doing CommandBar drawing. > mfc90d.dll!CDC::GetPixel(int x=0x00000018, int y=0x00000005) Line 594 + 0x3b bytes C++
HEIXT130D.dll!CXTPImageManagerIcon::CreateDisabledIcon(unsigned long clrDisabledLight=0x00f0f0f0, unsigned long clrDisabledDark=0x00a0a0a0) Line 2487 + 0x19 bytes C++ HEIXT130D.dll!CXTPOfficeTheme::DrawImage(CDC * pDC=0x0019d280, CPoint pt={...}, CSize sz={...}, CXTPImageManagerIcon * pImage=0x065d5d58, int bSelected=0x00000000, int bPressed=0x00000000, int bEnabled=0x00000000, int bChecked=0x00000000, int bPopuped=0x00000000, int __formal=0x00000001) Line 97 C++ HEIXT130D.dll!CXTPPaintManager::DrawControlToolBarParent(CDC * pDC=0x0019d280, CXTPControl * pButton=0x06581730, int bDraw=0x00000001) Line 1728 + 0x5e bytes C++ HEIXT130D.dll!CXTPPaintManager::DrawControl(CDC * pDC=0x0019d280, CXTPControl * pButton=0x06581730, int bDraw=0x00000001) Line 1085 + 0x67 bytes C++ HEIXT130D.dll!CXTPControl::Draw(CDC * pDC=0x0019d280) Line 538 C++ HEIXT130D.dll!CXTPCommandBar::DrawCommandBar(CDC * pDC=0x0019d280, CRect rcClipBox={...}) Line 1453 + 0x16 bytes C++ HEIXT130D.dll!CXTPCommandBarAnimation::OnPaint(CPaintDC & paintDC={...}) Line 320 + 0x39 bytes C++ HEIXT130D.dll!CXTPCommandBar::OnPaint() Line 1391 C++ mfc90d.dll!CWnd::OnWndMsg(unsigned int message=0x0000000f, unsigned int wParam=0x00000000, long lParam=0x00000000, long * pResult=0x0019d6c4) Line 2042 C++ |
Posted By: rdhd
Date Posted: 18 December 2017 at 5:26pm
|
Looks like you have to wait for a MS fix or avoid the CJ code that creates a disabled icon. You can create icons for each state. CJ should consider using DIBS to create the disabled icon and for any other path-critical code that makes lots of calls to GetPixel. |
Posted By: rdhd
Date Posted: 09 January 2018 at 10:19am
| Good news. I have been notified by Microsoft that a hotfix has been scheduled for release on Jan. 23. MS will let me know if the timeline changes. |
Posted By: rdhd
Date Posted: 20 January 2018 at 12:13pm
| Microsoft now says the update has been pushed back to 1/30/2018. |
Posted By: Alex67
Date Posted: 22 January 2018 at 10:41am
|
Hi Do you have a KB ? How can we be informed on the status of the fix ?
|
Posted By: barona
Date Posted: 30 January 2018 at 11:27am
| Any update on this? My company's product is severely hindered by this, and we cannot easily replace the GetPixel calls. Looking forward to an update. |
Posted By: davesmills
Date Posted: 30 January 2018 at 1:17pm
| I note that KB4058258 was released Jan 31. Not loaded it yet but the description is not promising - I cannot find any reference to this problem. |
Posted By: engy
Date Posted: 31 January 2018 at 2:04am
| Any news as it is 1/31/2018? |
Posted By: Crao
Date Posted: 31 January 2018 at 4:38am
|
Any news of the update ? |
Posted By: Lord_Demo
Date Posted: 31 January 2018 at 3:17pm
|
I just got off the phone with Microsoft about this issue. They advised me that they do not have any plans to resolve this issue until there March update. Anyone have any information that states otherwise? I was hoping they would have a faster patch or hotfix for this issue.
|
Posted By: CyberGonzo
Date Posted: 31 January 2018 at 7:11pm
|
Any news on the hotfix and where to get it ? Thx ------------- www.isobuster.com |
Posted By: FrankF
Date Posted: 01 February 2018 at 6:05am
Do you have more information about the hotfix? |
Posted By: rdhd
Date Posted: 01 February 2018 at 8:27am
|
Microsoft says the fix is in this update: https://support.microsoft.com/en-us/help/4058258/windows-10-update-kb4058258 |
Posted By: Lord_Demo
Date Posted: 01 February 2018 at 10:56am
|
Awesome Update has worked for me
|
Posted By: FrankF
Date Posted: 02 February 2018 at 3:10am
|
Thank you rdhd. It looks very good! |
Posted By: CyberGonzo
Date Posted: 07 February 2018 at 10:37pm
|
Applied the fix ... it worked (mere days ago) ... but now the problem has returned. Anybody else seeing this as well ? [UPDATE] Perhaps I posted to hastily. Though I'm not pretending I understand what happened, it seems now fixed. After I wrote above comment I triggered Windows to check for updates (It said it had checked yesterday and there were no updates). But after the manual trigger it found a cumulative update pack. I installed it, rebooted and the problem is gone (again ...) So ... fixed (again) ------------- www.isobuster.com |
Posted By: xang
Date Posted: 08 February 2018 at 4:25am
|
Confirmed on my end, too. ------------- Product: Xtreme Toolkit Pro (MFC) version 18.0.1 (with 1-year maintenance) Platform: Windows 10 RS2 (x64) Language: Visual C++ |