GDI or GDI+ when draw string.
Hello,
FastReport.net draw string using GDI+, is it a good idea?
This following is a article from http://blogs.msdn.com/michkap/archive/2005...27/432986.aspx:
A quick look at Whidbey's TextRenderer
Over the weekend, TheMuuj mentioned in a comment:
As far as I know, there are new classes in Whidbey for drawing text with GDI (as a result of GDI+'s questionable screen rendering in some cases). Are these based on DrawText?
This is not exactly the reason. There are two basic problems that come into play with GDI+:
* There are some performance issues caused by the somewhat stateless nature of GDI+, where device contexts would be set and then the original restored after each call.
* The shaping engines for international text have been updated many times for Windows/Uniscribe and for Avalon, but have not been updated for GDI+, which causes international rendering support for new languages to not have the same level of quality.
The object is the System.Windows.Forms.TextRenderer class, which has two methods that can be used to render text using GDI/Uniscribe rather than GDI+:
* DrawText - Draws the specified text at the specified location using the specified device context, font, and color.
* MeasureText - Measures the specified text when drawn with the specified font.
This class and these methods (which have several different overrides) allow WinForms to support new languages as the OS support is added. For example, the ELK support in Windows XP SP2 added font and rendering support to the operating system for Bengali and Malayalam, but versions 1.0 and 1.1 of the .NET Framework would not render these scripts properly, even when the right font was being used. However, version 2.0 (Whidbey) will be able to properly support these scripts whenever the OS can support them....
I have not personally experienced the performance issues but have beentold by people who have that the support can also very useful. I am more of a "language support" guy myself, though. :-)
FastReport.net draw string using GDI+, is it a good idea?
This following is a article from http://blogs.msdn.com/michkap/archive/2005...27/432986.aspx:
A quick look at Whidbey's TextRenderer
Over the weekend, TheMuuj mentioned in a comment:
As far as I know, there are new classes in Whidbey for drawing text with GDI (as a result of GDI+'s questionable screen rendering in some cases). Are these based on DrawText?
This is not exactly the reason. There are two basic problems that come into play with GDI+:
* There are some performance issues caused by the somewhat stateless nature of GDI+, where device contexts would be set and then the original restored after each call.
* The shaping engines for international text have been updated many times for Windows/Uniscribe and for Avalon, but have not been updated for GDI+, which causes international rendering support for new languages to not have the same level of quality.
The object is the System.Windows.Forms.TextRenderer class, which has two methods that can be used to render text using GDI/Uniscribe rather than GDI+:
* DrawText - Draws the specified text at the specified location using the specified device context, font, and color.
* MeasureText - Measures the specified text when drawn with the specified font.
This class and these methods (which have several different overrides) allow WinForms to support new languages as the OS support is added. For example, the ELK support in Windows XP SP2 added font and rendering support to the operating system for Bengali and Malayalam, but versions 1.0 and 1.1 of the .NET Framework would not render these scripts properly, even when the right font was being used. However, version 2.0 (Whidbey) will be able to properly support these scripts whenever the OS can support them....
I have not personally experienced the performance issues but have beentold by people who have that the support can also very useful. I am more of a "language support" guy myself, though. :-)
Comments
DrawText is good for UI text rendering and it is used in FastReport.Net to draw some UI text. However, the report text is rendered using GDI+ DrawString. DrawText can't be used here because it does not support printing.
"The text rendering offered by the TextRenderer class is based on GDI text rendering and is not supported for printing from Windows Forms. Instead, use the DrawString methods of the Graphics class."