none
Print Driver - DrvFillPath Issue RRS feed

  • Question

  • <xmp>I have a monolithic print driver built on and running on Windows 7. The printing application has one object to print - a complex single curve comprised of close to a miilion lines, segments, beziers, etc. When printing this job to any common bubble jet, the job print takes a total of 3 seconds to finish. When sending this same job to my driver, the job takes 18 minutes to finish. In my driver, I see that the application sends a single object via one single call to DrvFillPath. I take this call and punt it to EnfFillPath and it takes 18 minutes for EngFillPath to return. So all of the time is eaten up in the guts of GDI, not my driver. Send the same job to a common office printer, the job finishes in 3 seconds. If I go to the application which is doing the printing, and I select the object and break the curves apart, you can see that the object has been busted up into close to a million small objects. At this point, if I print the job to my driver, my driver recieves close to a million calls to DrvFillPath, and each time I punt the calls to EngFillPath. When I do this, the entire job only takes 3 seconds to finish in my driver, which matches the time on the other printers. So if you send my driver bunches of calls to DrvFillPath, and I punt each one to EngFillPath, my driver operates very quickly and produces quality output. But if I take the same job, and merely combine all those objects into one object which contains lots of curves, and then that is sent via one single call to DrvFillpath, and then I take that one single call and punt it to EngFillPath, the call vanishes into the GDI for 18 minutes before returning. When the long call finishes, I get the same high quality output and the finished job is identical. It just takes longer. much longer. Since the user does not have to bust the object apart in order to get quick output to common printers, I really don't want to require the user to bust the object apart in my driver. Is there something that the other drivers are doing that I am overlooking? I tried to force the GDI to bust up the object by doing the following... Within DrvFillPath, if an object contains more than one PATHDATA enumeration, return FALSE to force the object to be broken up. But when I do this, and return false to GDI, the GDI then spends 18 minutes in lala land generating a call to my DrvBitBlt. When the single call to my DrvBitBlt finally arrives, I punt it to EngBitBlt and the call goes through immediately. So even with this "idea" the GDI still spends 18 minutes trying to rendering the fill. I had thought of trying to bust up the PATHOBJ myself by using PATHOBJ_bEnum to parse the PATHOBJ into individual PATHDATA objects, and then one by one calling EngCreatePath, then punting the smaller PATHOBJ's to EngFillPath, but the problem is that my driver is User Mode, which Microsoft specifies for Windows 7, and in user mode you have access to practically all of the Eng support functions...with the very strange exception of EngCreatePath. I do not understand why the user mode use of EngCreatePath is not allowed. So is there something simple I am overlooking? How do I get my driver to process the massive single call to DrvFillPath quickly like other drivers? Or do I have no choice but to tell users that they have to break up their curves before sending jobs to my driver? Thanks in advance, Cary J. </xmp>
    Thursday, February 28, 2013 9:14 PM