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

[Julien Lafon]

On Tue, 29 Mar 2005 13:49:42 -0500, Adam Jackson <ajax at nwnk.net> wrote:
> On Tuesday 29 March 2005 07:58, Julien Lafon wrote:
> > On Sun, 27 Mar 2005 11:00:58 +0200, Egbert Eich <eich at suse.de> wrote:
> > > Having video and print active in a single threaded Xserver would force
> > > video output to wait for the print rendering to finish.
> >
> > Xprint applications are scheduled by the X server as normal X clients
> > and do not behave differently. I do not see a different of having two
> > video cards or one video card and a print screen in one Xserver.
> 
> Then you don't understand the problem.  See, for example:
> 
> https://bugs.freedesktop.org/show_bug.cgi?id=1426
> 
> 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.
We ran some tests this morning and there is no noticeable "stall" in
the video server operation when the print extension sends the job to
the spooler.

> 
> 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

> and is blocking trying to move
> that data out to the lpd.  When you're blocked on output then you don't
> return to the scheduling loop in small bounded time.  Which means the server
> appears to stall.
The Xprint extension code in the server spools the PDL data to a
temporary storage until XpEndDoc() is called by the client. If that
command is received the server calls fork() to create a new child
process from which the spooler command is launched. This operation is
completely asynchronous and does not interfere with the main server
thread until the child terminates which will trigger the creation of
the ENDDOC event.

[1] excluding OpenGL, but we take care about this issue in a separate project

Julien
-- 
Julien Lafon
Senior Staff Engineer, Hitachi