Querying Resource Usage 
Author Message
 Querying Resource Usage

Hi gurus & others,

I know postscript v1 quite well, but haven't followed recent
development or vendor extensions.

Old PS allowed to limit the printer's CPU time (jobtimeout), but
probably not to query it. Anyway, here's my topic:

At our department, they decided to charge users of the colour DIN A0
plotter for colour usage. That usage is currently estimated by a human
by looking at the output.

Now I wonder: It seems easy for PostScript to count the number of set
device pixels in any device colour. If one could querey such a counter
before and after each job, you would be done. However it seems, the
standard lacks that.

Can it be implemented in PostSCript without a huge performance penalty?

This brings up the general issue: Shouldn't be resources be queryable?
I think of "sheets of paper", "CPU seconds", "colour", etc. This seems
quite reasonable, but still, no vendor seems to have it, right?

Regards,
Ulrich.Windl (at rz.uni-regensburg.de)



Tue, 02 Mar 2004 18:01:01 GMT  
 Querying Resource Usage

Quote:

>Now I wonder: It seems easy for PostScript to count the number of set
>device pixels in any device colour.

No, there are no PostScript operators that count pixels. No printer
I've heard of keeps a count.

Quote:

>Can it be implemented in PostSCript without a huge performance penalty?

Pixel counting can't be done at all. You could redefine the colour
setting operators to do some analysis.

Quote:

>This brings up the general issue: Shouldn't be resources be queryable?
>I think of "sheets of paper"

That's not really a resource, but some printers do keep a count. It is
printer dependent if they do, and how to ask. Also, in many printers
PostScript processing is asychronous, and so the number of pages
printed by a job cannot be discovered by querying a hardware sheet
counter within the job.

Quote:
>"CPU seconds"

Most printers don't care about CPU utilisation, since they have no
other task to do...

Quote:
> "colour"

Not a resource.
----------------------------------------

Visit http://www.*-*-*.com/ ,
PSAlter, psalters, tea, and small {*filter*} animals. And stuff.  


Tue, 02 Mar 2004 18:21:53 GMT  
 Querying Resource Usage

Quote:


> >Now I wonder: It seems easy for PostScript to count the number of set
> >device pixels in any device colour.

> No, there are no PostScript operators that count pixels. No printer
> I've heard of keeps a count.

Huh?
The infill and instroke and similar operators do just this.

--
Many thanks,

Don Lancaster
Synergetics   3860 West First Street  Box 809  Thatcher, AZ 85552

Please visit my GURU's LAIR web site at http://www.tinaja.com



Sun, 07 Mar 2004 11:24:19 GMT  
 Querying Resource Usage

Quote:



> > >Now I wonder: It seems easy for PostScript to count the number of set
> > >device pixels in any device colour.

> > No, there are no PostScript operators that count pixels. No printer
> > I've heard of keeps a count.

> Huh?
> The infill and instroke and similar operators do just this.

Count pixels?  I don't think so.  These are hit test operators.  For a
specified location or path, they indicate whether or not there's an
intersection with the current path in the graphics state.  You could,
of course, iterate over every possible device pixel and count the ones
which return true, but that seems pretty labor-intensive.

-pd



Sun, 07 Mar 2004 21:23:35 GMT  
 Querying Resource Usage

Quote:




> > > >Now I wonder: It seems easy for PostScript to count the number of set
> > > >device pixels in any device colour.

> > > No, there are no PostScript operators that count pixels. No printer
> > > I've heard of keeps a count.

> > Huh?
> > The infill and instroke and similar operators do just this.

> Count pixels?  I don't think so.  These are hit test operators.  For a
> specified location or path, they indicate whether or not there's an
> intersection with the current path in the graphics state.  You could,
> of course, iterate over every possible device pixel and count the ones
> which return true, but that seems pretty labor-intensive.

Still I think it could be done, maybe with some hardware
acceleration. I'm mostly surprised that no-one had the idea
before. OK, modern ink tanks have electronics to report their filling
state, but wouldn't be a standard language to query such things great?

Ulrich



Tue, 16 Mar 2004 20:36:07 GMT  
 Querying Resource Usage

Quote:

>> Count pixels?  I don't think so.  These are hit test operators.  For a
>> specified location or path, they indicate whether or not there's an
>> intersection with the current path in the graphics state.  You could,
>> of course, iterate over every possible device pixel and count the ones
>> which return true, but that seems pretty labor-intensive.

>Still I think it could be done, maybe with some hardware
>acceleration. I'm mostly surprised that no-one had the idea
>before. OK, modern ink tanks have electronics to report their filling
>state, but wouldn't be a standard language to query such things great?

The PostScript language was *very* carefully designed so that it does
not give access to pixel information. The reason is simple: PostScript
may not be interpreted in a context where pixel information is
available.

A common and obvious case of this is Distiller, which converts vector
PostScript directly to vector PDF, without rendering to pixels.

A less obvious but perhaps even more important case is large format
devices including imagesetters. These usually convert the PostScript
into a display list, still vector.  This display list is processed -
later, possibly after the end of interpretation, and possibly on
different processors - into the pixels required.
----------------------------------------

Visit http://www.*-*-*.com/ ,
PSAlter, psalters, tea, and small {*filter*} animals. And stuff.  



Thu, 18 Mar 2004 21:20:54 GMT  
 Querying Resource Usage


Quote:
>This display list is processed -
>later, possibly after the end of interpretation, and possibly on
>different processors - into the pixels required.

So, why not process from the beginning into the pixels finally
required?

regards

Heinz Kusznier



Sat, 19 Jun 2004 06:50:42 GMT  
 Querying Resource Usage

Quote:



>>This display list is processed -
>>later, possibly after the end of interpretation, and possibly on
>>different processors - into the pixels required.

>So, why not process from the beginning into the pixels finally
>required?

Because the pixel data is typically enormously larger than the display
list. The display list will often fit into RAM, while the pixel data
can't (or certainly couldn't, at the time these devices were first
designed, over a decade ago; some can probably be configured to work
entirely in RAM now).

A 20" x 30" sheet at 4000 dpi in monochrome requires over a gigabyte
for the raw bitmap.

Since imagesetters typically do have disk backing store, this may not
seem an obstacle. But there is typically less disk activity in writing
and reading a sequential display list, than in doing random writes to
a pixel map, though of course the complexity of the display list is
unbounded while that of the pixel map is bounded.  

An imagesetter has to keep up; once the sheet of film starts moving,
it must move at a constant rate, and the film is ruined if the pixels
are not ready.  Because the display list is unbounded this could
occasionally happen. Perhaps in this case, the imagesetter will
pre-render to a pixel map on disk. Slower, but a rare occurrence.
----------------------------------------

Visit http://www.*-*-*.com/ ,
PSAlter, psalters, tea, and small {*filter*} animals. And stuff.  



Sat, 19 Jun 2004 18:47:34 GMT  
 
 [ 8 post ] 

 Relevant Pages 

1. resource usage

2. ASP Resource Usage ???

3. Resource usage: WSH vs Command-Shell

4. query on a query

5. SELECT queries - Use Access query or not?

6. Win32_Process ( CPU Usage ) Issue

7. Usage of PostScript for Pagemaker IBM<->Mac transfers

8. VM usage of Type 42 fonts

9. Small Caps Usage

10. Agfa P3400PS- 2nd tray usage

11. Monitoring Toner Usage

12. bounding ghostscript memory usage

 

 
Powered by phpBB® Forum Software