[Mono-bugs] [Bug 79822][Nor] Changed - "new PrintDialog()" takes ~2 seconds on linux

[bugzilla-daemon at bugzilla.ximian.com]

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

Changed by toshok at ximian.com.

http://bugzilla.ximian.com/show_bug.cgi?id=79822

--- shadow/79822	2006-11-10 06:49:36.000000000 -0500
+++ shadow/79822.tmp.8025	2006-11-10 09:00:14.000000000 -0500
@@ -63,6 +63,23 @@
 Yep, the new gtk printing backend caches the list of printers but
 doesn't use cupsGetDests to get the printer list.
 
 So the heart of the problem is, when should the printer list get
 updated ? I mean, caching some strings, removing and adding them, is
 not a big problem.
+
+------- Additional Comments From toshok at ximian.com  2006-11-10 09:00 -------
+My suggestion is to stop using the PrintingServices* classes as
+singletons.  We'll have 1 global one to handle the static
+PrinterSettings.InstalledPrinters, but the PrinterSettings instances
+as well as the PrintDialog instances should be talking to an instance
+(preferably the same) of PrintingServicesUnix.  It'll be created as
+its needed and shared amongst the other objects.
+
+cupsGetDests is a time consuming call to be sure, as are the other
+cups calls made by PrintingServicesUnix.  We can make the list code
+async by firing off the async request when a new PrintingServicesUnix
+is created and populate the dialog with those results.  But the main
+problem is that we seem to be invoking those same synchronous cups
+calls multiple times when bringing up the print dialog and futzing
+with things.  We need to cache the return values at least for the
+lifetime of the print dialog.  No other caching should be necessary.