WPF equivalent of TextOut()
in [CSharp]
|
From: Bob on 31 May 2010 16:24 You have to use GlyphRun - you can do that by getting a drawing context. A few corrections for the posts above: 1. Unicode does not mean converting chars from 256 (ASCII) encoding to 32 bit, by using the "T" macros - in fact the maximum enconding strength of Unicode is 21bits. What Unicode means is a standard for associating properties to a character like name, equivalent representations, mirroring, unique and immutable number etc. Some characters are not meant to be displayed - these include directionality control characters used when writing right to left text, paragraph and line breaks etc. Other more important characters include ligatures (fi, ffi) and combining marks (for example diacritics used in French). Shortly Unicode is very difficult to handle - the fact that MS have exposed a crippled API for text rendering and people don't understand that fact does not make Unicode easier. 2. WPF is not a different paradigm or new one for that matter - in fact MS have been experimenting with visual trees in DirectX ten years ago, but they were thrown to the garbage (if you see a shooter game developed with retained DirectX let me know). 3. WPF is not fast for changing graphics - in fact it is much slower that GDI due to the need to rebuild the visual tree - it may be faster for static "UI" based images, but is not a good solution for dynamic/real time visualization exactly because it cannot simply render a text or even a rectangle without having to put extra pressure on the GC. If you want to have full control over text rendering + amazing speed I suggest to throw the MS stuff aside and use an open source library like FreeType that provides complete control over glyph rendering combined with an open source library to handle Unicode. Then you can generate glyph images, put them in textures and render very very fast without going through managed stuff at all (actually this is what WPF does in the background anyway). That is only of course you need "serious" text out... Best regards, Bob Peter Olcott wrote: WPF equivalent of TextOut() 12-Feb-10 What is the Windows Presentation Foundation equivalent of the original Win32 API function TextOut()? BOOL TextOut( HDC hdc, // handle to device context int nXStart, // x-coordinate of starting position int nYStart, // y-coordinate of starting position LPCTSTR lpString, // pointer to string int cbString // number of characters in string ); Previous Posts In This Thread: On Friday, February 12, 2010 12:01 PM Peter Olcott wrote: WPF equivalent of TextOut() What is the Windows Presentation Foundation equivalent of the original Win32 API function TextOut()? BOOL TextOut( HDC hdc, // handle to device context int nXStart, // x-coordinate of starting position int nYStart, // y-coordinate of starting position LPCTSTR lpString, // pointer to string int cbString // number of characters in string ); On Friday, February 12, 2010 12:23 PM Seetharam wrote: WPF is a different paradigm... not like GDI. WPF is a different paradigm... not like GDI. You would typically have a "Label"/"Content" element and you woudl assign the "Text" property with the text you want. -Seetharam On Friday, February 12, 2010 12:24 PM Peter Duniho wrote: Peter Olcott wrote:AFAIK, there is no WPF-specific API for that. Peter Olcott wrote: AFAIK, there is no WPF-specific API for that. WPF has a declarative object model, not an imperative model. To display text, you have to create a text output object (e.g. Label) and place it in the appropriate place within your visual data structures. That said, I believe that there is nothing to stop you from using either the Graphics.DrawString() method or the TextRenderer.DrawText() method, assuming that you do in fact have a Graphics instance to work with or equivalent. Pete On Friday, February 12, 2010 3:18 PM Andy O'Neill wrote: What do you want to achieve? What do you want to achieve? To put a piece of text in a specific part of the screen is a rather strange requirement for WPF. You could do it by having a canvas that covered the enture screen, Add a textblock as a child. Whack your text in . Position the text box. Make it on top of everything else. Done. On Friday, February 12, 2010 9:25 PM Peter Olcott wrote: "Andy O'Neill" <aon14nocannedmeat(a)lycos.co. "Andy O'Neill" <aon14nocannedmeat(a)lycos.co.uk> wrote in I want to put text on the screen so I can build my deterministic finite automaton glyph recognizer. www.OCR4Screen.com One aspect of this that I think the .NET platform may make simpler is handling Unicode, is this correct? If not, then the only reason (that I can currently see) is to use WPF is for the promised graphics hardware acceleration. On Saturday, February 13, 2010 3:41 AM Peter Duniho wrote: Peter Olcott wrote:You do not need an equivalent to TextOut() for that. Peter Olcott wrote: You do not need an equivalent to TextOut() for that. You just need to write a proper WPF application, where when you want text to show up on the screen, you just add the appropriate kind of text object to your visual objects graph. WPF will take care of rendering it for you. I do not find the unmanaged API handling of Unicode difficult. The most tedious part is writing code that is character-encoding-agnostic (i.e. uses the _t string handling functions, TEXT macro, etc.), but most of the time it is not bad. That said, since .NET is 100% Unicode for all of its string and character handling, you never have to worry about that sort of portability in your code. But, any place your .NET code has to interact with the outside world and in particular, any time the outside world uses something other than Unicode, you still wind up having to do similar things to manage the conversion back and forth. You do not need any graphics acceleration if all you are doing is displaying text. Note that in .NET, there is also the venerable Forms API, which is much more like the Windows "user.dll" API. If you are looking to move from the unmanaged Win32 API to .NET, the learning curve will be lower if you use Forms instead of WPF. Pete On Saturday, February 13, 2010 11:21 AM Peter Olcott wrote: I am generating millions of glyphs, and this is the timeconsuming part of DFA I am generating millions of glyphs, and this is the time consuming part of DFA creation. I want to speed this part up. On Saturday, February 13, 2010 1:42 PM Peter Duniho wrote: Peter Olcott wrote:Let me rephrase then: 3D graphics acceleration support (i.e. Peter Olcott wrote: Let me rephrase then: 3D graphics acceleration support (i.e. the kind of acceleration WPF takes advantage of) is not going to speed up drawing of text. Video drivers have had 2D acceleration for a couple of decades now. You can safely assume that any of the APIs take advantage of that where possible. WPF is not required for that. Pete On Saturday, February 13, 2010 2:20 PM Peter Olcott wrote: This reference below disagrees with your statement:http://en.wikipedia. This reference below disagrees with your statement: http://en.wikipedia.org/wiki/Windows_Presentation_Foundation DirectX 10 cards are able to cache the font glyphs in video memory, then perform the composition (assembling of character glyphs in the correct order, with the correct spacing), alpha-blending (application of anti-aliasing), and RGB blending (ClearType's sub-pixel color calculations), entirely in hardware. On Saturday, February 13, 2010 2:30 PM Peter Duniho wrote: Peter Olcott wrote:Well, a) WPF does not guarantee DX10, and b) it is not Peter Olcott wrote: Well, a) WPF does not guarantee DX10, and b) it is not clear to me that this is going to produce a speedup relative to the 2D acceleration already available. But, by all means: implement your code using WPF if you feel it will improve the situation. I do not mean to discourage you from trying something new! Pete On Saturday, February 13, 2010 5:10 PM David Ching wrote: Have you checked if DirectWrite would serve as a native solution?-- David Have you checked if DirectWrite would serve as a native solution? -- David On Sunday, February 14, 2010 8:53 AM Peter Olcott wrote: It looks like DirectWrite is most likely the underlyingtechnology of the glyph It looks like DirectWrite is most likely the underlying technology of the glyph generation aspect of WPF. Submitted via EggHeadCafe - Software Developer Portal of Choice Task Parallelism in C# 4.0 with System.Threading.Tasks http://www.eggheadcafe.com/tutorials/aspnet/21013a52-fe11-4af8-bf8b-50cfd1a51577/task-parallelism-in-c-4.aspx
|
Pages: 1 Prev: Health monitoring and the event log Next: Installing Visual Studio 2010 Express |