Sorry for blogging in English. I know that I am breaking my own rules 😉
Reasons for this article:
In the last years I found it more an more complicated to get bugs fixed in current software produced by Microsoft. My experience showed me, that the Microsoft product teams always look for new versions and new features and the Microsoft support teams and engineers don’t produce enough pressure that well known bugs get fixed in the currently used software products.
The reason why the Microsoft support rejected a request for a fix was very often that not enough customers are affected by the problem or bug. And this is often a problem for me and my company. We are just a small ISV so we can’t point to millions of affected users. And yes I know that hotfixes are expensive.
So usually we have to be flexible and have to find work arrounds.
But my feeling is that there would be enough impact and pressure for a hotfix, if it would be known to the public what problems exist and that there are others who have a request to get a special problem fixed.
Also a lot of programmers tend to avoid the creation of a support request, because the experience shows: You put energy, time (and money) into a support request and the answers are in most cases: Will not get fixed, by design, and so on…
Another experience in the last years was, that even being an MVP doesn’t help to get anything fixed by Microsoft even if a lot of MVPs point out that there is a real need for a change or fix.
So I just want to choose a new way, because there is no way to get votes of other people to a standard bug in a Microsoft product like it is possible on Microsoft Connect. But Connect is absolutely worthless if the product is already shipped!
I want to collect votes for this problem via my blog. I also informed the Microsoft support engineer who cares about the current incident.
If you agree and if you see a larger problem in this bug too, or if you have the feeling or knowledge that it has impact on your own software, than please write a comment to this blog article. Please leave your real email address or homepage URL. The email address will not be visible to the public, and I will forward it only to Microsoft if the poster agrees.
Description of the bug:
On January 17th, 2009 I reported a reproducible bug in Windows Vista in the article DrawText unter Vista gegenüber XP um bis zu Faktor 50 langsamer! (The article is written in German, you find a description in English below in the next lines)
Fact:
Windows Vista and Window 7 are up to 50 times slower in the execution of a simple DrawText function with DT_CALCRECT set compared to Windows XP.
You can find the source code for a sample code (VS-2005 MFC project) that shows the bug here: TestDrawText.zip. If you are just interested in the executable you can find it here TestDrawTextExe.zip.
And as far as I can see the overall performance of DrawText is affected.
My request:
If you find it important that this need a fix, or if you have the feeling or the knowledge, that you software might be effected. Please leave a comment here ❗
Or feel free to vote on the bug I filed for Windows 7 on Microsoft Connect:
https://connect.microsoft.com/windows7/feedback/ViewFeedback.aspx?FeedbackID=401007
Thank you ❗
Final Note (11.07.2009):
Read on here http://blog.m-ri.de/index.php/2009/07/11/ausloesung-drawtext-unter-vista-gegenueber-xp-um-bis-zu-faktor-50-langsamer/
My opinion would depend on what the cause of the performance hit is and how it can be adjusted? Is it doing something useful? Necessary? Can there be a flag for a compatibility mode that avoids it?
I’ve just tested your code on my Vista and XP machines:
On XP it is 65 times faster than on Vista.
I’ve tried to vote on connect, but:
„Page Not Found
The content that you requested cannot be found or you do not have permission to view it.“
A search for the Feedback-ID yields to „Invalid Feedback ID.“
Hi Chris!
I can open the link on connect. Are you sure that you are memeber of the Windows 7 Beta program on connect?
Hi Martin,
no I’m not a member of the Win7 Beta. I’ve just read your blog and tested the issue under XP and Vista. And because it’s so slow under Vista, I don’t realized that your link is for Win7.
Sorry, I can’t vote.
Hello Martin,
I totally support your case! I’m a developer and am writing a small note management application called CintaNotes. Because of the lame DrawText in Vista I had to implement my own word-breaking routine.
Wish you best of luck!
Nabend. Eine etwas unpassende Frage aber wie kann ich diesen Blog zu meinem Google Feedreader hinzufuegen? Finde keinen Link. Auf jedenfall ein toller Beitrag.
Ich kenne den Google Feed Reader nicht.
Aber das RSS Feed Symbol findest Du rechts außen im Sidebar.
Die Feed-Adresse lautet http://blog.m-ri.de/index.php/feed/
Danke für den Blog!
Ich entwickle ein TMS-System, das viele Bildschirmausgaben mit Draw_Text macht. War schon total verzweifelt, weil ab Vista alles so unerträglich langsam wurde, und die Kunden eben den zackigen Speed vom XP gewohnt waren.
Hat schon jemand eine sinnvolle alternative zu Draw_Text gefunden, die unter Win7 läuft, und schneller ist?
Es gibt kene alternative. Früher war das GDI das niegrigste System und damit das schnellste. Die Ursachen für das langsamere DrawText unter Vista und später liegt eher im Sprachen und Unicode System begründet als im GDI.
Es gibt auch nandere Gründe, aber lies meinen Artikel, die Hauptursachen liegen in der Unicode Behandlung.
GDI unter Windows Vista und später ist nicht mehr Hardware beschleunigt, da das GDI alles an den Desktop Window Manager weitergibt. GDI+ wäre IMHO schneller.
Aber ich würde es erstmal mit TextOut oder ExTextOut versuchen.
Aber ich frage mich bitte wo ist DrawText wirklich ein zeitkritisches Problem?