WPF equivalent of TextOut()
in [MFC]
|
Prev: VC++
Next: "Problems"
From: Peter Duniho on 13 Feb 2010 03:41 Peter Olcott wrote: > I want to put text on the screen so I can build my > deterministic finite automaton glyph recognizer. > www.OCR4Screen.com You don't 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. > One aspect of this that I think the .NET platform may make > simpler is handling Unicode, is this correct? I don't 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's 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. > If not, then the only reason (that I can currently see) is > to use WPF is for the promised graphics hardware > acceleration. You don't need any graphics acceleration if all you're 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're looking to move from the unmanaged Win32 API to .NET, the learning curve will be lower if you use Forms instead of WPF. Pete
From: Peter Olcott on 13 Feb 2010 11:21 "Peter Duniho" <no.peted.spam(a)no.nwlink.spam.com> wrote in message news:eH2zmhIrKHA.3408(a)TK2MSFTNGP06.phx.gbl... > Peter Olcott wrote: >> I want to put text on the screen so I can build my >> deterministic finite automaton glyph recognizer. >> www.OCR4Screen.com > > You don't 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. > >> One aspect of this that I think the .NET platform may >> make simpler is handling Unicode, is this correct? > > I don't 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's 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. > >> If not, then the only reason (that I can currently see) >> is to use WPF is for the promised graphics hardware >> acceleration. > > You don't need any graphics acceleration if all you're > doing is displaying text. I am generating millions of glyphs, and this is the time consuming part of DFA creation. I want to speed this part up. > > Note that in .NET, there is also the venerable Forms API, > which is much more like the Windows "user.dll" API. If > you're looking to move from the unmanaged Win32 API to > .NET, the learning curve will be lower if you use Forms > instead of WPF. > > Pete
From: Peter Duniho on 13 Feb 2010 13:42 Peter Olcott wrote: > I am generating millions of glyphs, and this is the time > consuming part of DFA creation. I want to speed this part > up. Let me rephrase then: 3D graphics acceleration support (i.e. the kind of acceleration WPF takes advantage of) isn't 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
From: Peter Olcott on 13 Feb 2010 14:20 "Peter Duniho" <no.peted.spam(a)no.nwlink.spam.com> wrote in message news:u5rzYxNrKHA.5036(a)TK2MSFTNGP02.phx.gbl... > Peter Olcott wrote: >> I am generating millions of glyphs, and this is the time >> consuming part of DFA creation. I want to speed this part >> up. > > Let me rephrase then: 3D graphics acceleration support > (i.e. the kind of acceleration WPF takes advantage of) > isn't 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 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.
From: Peter Duniho on 13 Feb 2010 14:30
Peter Olcott wrote: > 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. Well, a) WPF doesn't guarantee DX10, and b) it's 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 don't mean to discourage you from trying something new! Pete |