gdiplus benefits from valgrind testing when running DNS 9.0

[Susan Cragin]

-----Original Message-----
>From: Nikolay Sivov <bunglehead at gmail.com>
>Sent: Jun 28, 2008 9:23 AM
>To: Susan Cragin <susancragin at earthlink.net>
>Cc: Wine Developers <wine-devel at winehq.org>
>Subject: Re: gdiplus benefits from valgrind testing when running DNS 9.0
>
>Susan Cragin wrote:
>> -----Original Message-----
>>   
>>> From: Nikolay Sivov <bunglehead at gmail.com>
>>> Sent: Jun 28, 2008 8:44 AM
>>> To: Susan Cragin <susancragin at earthlink.net>
>>> Subject: Re: gdiplus benefits from valgrind testing when running DNS 9.0
>>>
>>> Susan Cragin wrote:
>>>     
>>>> Whoops. Forgot one thing. 
>>>> When trying to run the program again, after the install, the following error prevents it from running again. 
>>>>
>>>> fixme:gdiplus:GdipCreateHBITMAPFromBitmap stub
>>>> wine: Call from 0x7b845630 to unimplemented function gdiplus.dll.GdipCreateLineBrushFromRectWithAngleI, aborting
>>>> fixme:dbghelp:dump_system_info fill in CPU vendorID and feature set
>>>>
>>>>
>>>>
>>>> -----Original Message-----
>>>>   
>>>>       
>>>>> From: Susan Cragin <susancragin at earthlink.net>
>>>>> Sent: Jun 28, 2008 8:27 AM
>>>>> To: Wine Developers List <wine-devel at winehq.org>
>>>>> Subject: gdiplus benefits from valgrind testing when running DNS 9.0
>>>>>
>>>>> I tried installing and running Dragon NaturallySpeaking 9.0 yesterday with wine's gdiplus. 
>>>>> wine-1.1.0
>>>>>
>>>>> The program installed well, and training worked, too. Recognition during training was fast enough to keep up. Running it worked up to a point, but when it finally crashed I was trying something that doesn't always work anyway. 
>>>>>
>>>>> Here are the install gdiplus warnings:
>>>>>
>>>>> fixme:gdiplus:GdipSetLinePresetBlend not implemented
>>>>>
>>>>> fixme:gdiplus:GdipCreateHBITMAPFromBitmap stub
>>>>>
>>>>> fixme:shell:SHAppBarMessage msg=6, data={cb=36, hwnd=0x60058, callback=7c80a46c, edge=2081853302, rc=(589886,13361216)-(2081853346,13361216), lparam=cc00b0}: stub
>>>>>
>>>>> fixme:gdiplus:GdipCreateHBITMAPFromBitmap stub
>>>>>
>>>>> fixme:shell:SHAppBarMessage msg=2, data={cb=36, hwnd=0x60058, callback=7c1520e1, edge=1, rc=(0,0)-(800,28), lparam=ffffffec}: stub
>>>>>
>>>>> fixme:gdiplus:GdipCreateHBITMAPFromBitmap stub
>>>>>
>>>>> err:ntdll:RtlpWaitForCriticalSection section 0xcc3bb8 "?" wait timed out in thread 00dd, blocked by 005e, retrying (60 sec)
>>>>>
>>>>> fixme:gdiplus:GdipCreateHBITMAPFromBitmap stub
>>>>>
>>>>> fixme:shell:SHAppBarMessage msg=6, data={cb=36, hwnd=0x60058, callback=cbf41c, edge=2081853302, rc=(1638456,13361216)-(2081853346,13361216), lparam=cc00b0}: stub
>>>>>
>>>>> fixme:shell:SHAppBarMessage msg=6, data={cb=36, hwnd=0x60058, callback=cbf470, edge=2081853302, rc=(1638456,13361216)-(2081853346,13361216), lparam=cc00b0}: stub
>>>>>
>>>>> fixme:gdiplus:GdipCreateHBITMAPFromBitmap stub
>>>>>
>>>>> fixme:oleacc:AccessibleObjectFromWindow 0x1009a 0 {618736e0-3c3d-11cf-810c-00aa00389b71} 0x33f17c
>>>>>
>>>>> -------------------------------
>>>>> Here are the run warnings:
>>>>> -------------------------------
>>>>>
>>>>> fixme:gdiplus:GdipCreateHBITMAPFromBitmap stub
>>>>>
>>>>> wine: Call from 0x7b845630 to unimplemented function gdiplus.dll.GdipCreateLineBrushFromRectWithAngleI, aborting
>>>>>
>>>>>
>>>>> err:ntdll:RtlpWaitForCriticalSection section 0x7bc932c4 "loader.c: loader_section" wait timed out in thread 00dd, blocked by 003a, retrying (60 sec)
>>>>>
>>>>> This next one eventually crashed the program. 
>>>>>     
>>>>>         
>>> I think I could fill this gap (GdipCreateLineBrushFromRectWithAngleI) 
>>> next week. There's nothing to stop this, I mean any
>>> others unimplemented features of GDI+.
>>>     
>>
>> Let me clarify as well as I am able why I sent this message, because I am not a developer, just a tester, and I know you are not familiar with Dragon NaturallySpeaking. 
>> A couple of weeks ago, non-native gdiplus was essential to training the DNS 9.0 voice model. Training was so slow between speech and recognition that training wouldn't complete. That is no longer the case. The recognition model works fast enough to complete training. In fact, it works very fast. 
>>   
>Sounds good. So you think performance increases actually due gdiplus 
>changes? As for me I don't think so

To be honest, I don't know because I'm not a programmer. I usually filter my findings through Dan Kegel. But I can tell you that training didn't complete last week, due to gdi problems, and it completes now. And the errors I see that led to the eventual program crash appear to be gdi errors.