• Post Reply Bookmark Topic Watch Topic
  • New Topic

Any success using threads to isolate printing functions?

 
John Richardson
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello everyone-
I posted this in the Swing/AWT group, but it might make more sense here:
This is my first post in this particular forum because I've just recently been tasked with some presentation-side stuff, and I'm getting a crash course in Swing/AWT (mostly AWT due to client restrictions)!
I've got a rather large problem with printing speed, and was wondering if anyone has had any success with threading print operations to allow GUI interaction to continue for the user while a print job is spooling/printing? I tried to thread my print method, and set the priority to Thread.MIN_PRIORITY but to no avail. My printing is still tying up almost all of the bandwidth.
Thanks for any input or alternate strategies you can offer.
John
 
Joe Ess
Bartender
Posts: 9362
11
Linux Mac OS X Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I don't think putting printing logic into a separate thread would have much of an effect on performance. First, if the activity is processor bound, that is, limited by the speed of the CPU, creating another thread will add to the processor load because of the additional context switching. Multithreading doesn't let you perform one slow task faster, it lets you do two things at the same time.
Printing also uses a huge amount of memory. Multithreading would have no positive effect on available memory. Watch your app's memory consumption with top (*nix) or task manager (windows). If you are running out of available memory and your disk is thrashing, your app's performance is being held back as the OS tries to swap memory to disk and back again. Make sure your hardware is up to the task.
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
All of what Joe said is dead on. Threads don't make things run faster, but they can make the system feel faster and users more productive if the UI is "responsive" while your printing is running. Swing encourages you to run any long-running task on its own thread just to keep the UI open. Of course you have to study up on SwingUtil to send any updates back into the UI from another thread. Donno if any of that applies well to AWT.
I don't know printing code at all. Do you set up a single call to the API that does all the work? If so, you probably can't do much about it eating all the CPU. My Win98 machine at home slows to a crawl while printing. Yuck. But ... if you're looping through your data, sending one part at a time to the printer, you might find a place to wait() now and then so other processes get a shot at the CPU.
 
John Richardson
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks to both of you for your reply. I do understand that threading is not going to allow me to make my printing faster. My original problem (which I should have noted) was that one of our users wanted to manipulate the GUI while something went to the printer. The printer would just take over everything. I don't think they were able to use the GUI at all when something went to the printer before, which made me think that threading it would make their user experience better. It may still be a must have in order to allow the possibility of that occuring.
But threading didn't seem to alleviate my problem because although the user (me in this case) could manipulate the GUI somewhat, the print spooling still took almost all of the bandwidth. I would click on the "Open" icon to open a new doc in the GUI, and it would wait until at least 2 more pages had spooled (15-30 secs) before it got there. I'm sure they have a lot bigger docs than the one I'm trying to print as a test(4 page TIFF), which leads me to believe they're not going to satisfied... and I don't want that.
I'm not really sure where to go at this point. The printing call could be a little broken up maybe... I'm going to look at that. Maybe I need to try and just make the image smaller before it goes to the printer... hopefully with little loss in quality. O, the trials of a developer
Thanks again-
John
[ April 28, 2004: Message edited by: John Richardson ]
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I may be dreaming, but I thought my printer started taking too much CPU after a catastrophic failure trying to print many-meg pictures from ACD-See and then I re-installed the drivers. I'm pretty sure it was not such a pain before that. Is this a direct-connected printer? Have you tried the manufacturer's help desk? Maybe there is some way to tune its priority.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!