[Xprint] Re: Unified video+print Xserver / was: Re:Modularization mailing list and initial strawman proposal

[Roland Mainz]

Julien Lafon wrote:
[snip]
> > X's scheduler is not preemptive.  When it schedules a client, that client is
> > going to run to the completion of at least one request in its queue.  With
> > core X this is not a huge deal, because each request is simple.  With GLX
> > this can be a problem, because "one request" can be "draw these 40,000
> > multitextured supersampled quad strips".  Oops.
> This seems to be an unique problem of the GLX implementation.

One possible workaround may be to copy the design of the GLX
implementation in Solaris which runs the OpenGL engine in a seperate
thread (the Xserver itself doesn't need to be multithreaded for that,
AFAIK only the loadable GLX module in Xsun makes sure it itself protects
properly when being called from various threads).

[snip]
> > My understanding of Xprint is that the invoked lpd (or whatever) is not
> > scheduled like an X client but is instead treated like an output device.
> > Which means you can have a situation where the server has a huge chunk of
> > data (say, a rasterised page of A4 at 600dpi),
> The Xprint drivers do not rasterise anything[1] in the server. This
> resembles somehow an item roland collected:
> http://xprint.mozdev.org/docs/Xprint_FAQ.html#id2807877

Erm... no. Xprint itself does not define anything whether the print job
is rasterized in the Xserver, in the printer or elsewhere. The DDX
itself decides whether it generates vector data or rasterizes itself.
For example the PostScript, PDF and SVG drivers are pure vector DDX
(which means they generate vector data and send them to the printer) but
the RASTER, MNG and GIF drivers are rasterizing within the DDX (the
PCL*-drivers are a wild mixture of both vector and normal DDX).

----

Bye,
Roland

-- 
  __ .  . __
 (o.\ \/ /.o) roland.mainz at nrubsig.org
  \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix programmer
  /O /==\ O\  TEL +49 641 7950090
 (;O/ \/ \O;)