dps-devel

Re: [Dps-devel] moving along

[Juliusz C. <jc...@pp...>]

TW> i am happy to report that i can now get the example program from
TW> chapter 8 (that i mentioned before) to work! which also means i
TW> was able to compile and install the dps extension.

Congratulations.

TW> i was wondering what i should move onto now, suggestions
TW> welcome. i was thinking of spending the weekend doing more reading
TW> (i still have the "Client Library Supplement for X", the "pswrap
TW> Ref Manual", and the "Display Postscript Toolkit for X" to read
TW> through).

I would also suggest the second edition of the PostScript Language
Reference Manual.  (Not the third one, which removes the DPS section.)

TW> i would also like to find the source to "pswrap" and try to figure
TW> out why i wants to insert the line:

TW> 	#include "psops.h"

TW> instead of:

TW> 	#include <DPS/psops.h>

TW> into the generated *.c file.

I'll check what the Solaris version does and come back to you.

TW> maybe i should start reading through the existing dps code? maybe i 
TW> should try to understand the gs code more? maybe i should play around 
TW> more with writing dps applications?

Why don't you start with the Adobe DPS demos?  They are an
enlightening read.

You'll find the original sources in the DPS anonymous FTP directory,
although you'll need to hack them somewhat in order to get them to
build on an XFree86 system.  Oh, yeah, many of them require Motif and
UIL (and therefore won't work with Lesstif).

TW> how would one monitor the system's memory (to observe the leaks)? when 
TW> the application terminates is the leaked memory reclaimed or does the X 
TW> server need to be restarted?

In dps-0.0.6, it is leaked.  In my private devel tree, there's a
working garbage collector for *local* VM, although not all local VM is
freed as yet.  Fixing this is very high on my todo list.  (Although
the highest item is fixing the two known issues of memory corruption,
a frustrating problem on which I've spent quite a few nights with no
results.)

All global VM is still leaked.  Fixing this will require a fairly
major reworking of Ghostscript.

In order to trace memory allocations, you could build a debugging
version of the extension and use the relevant switches in your config
file.  See dps' README file on how to do that, and Ghostscript's
``Use.htm'' for a list of debugging switches.

TW> this list sure is quiet. is there any development going on "behind this 
TW> list's back" that i should be aware of?

As far as I know, I am the only person working on the DPS extension.
I've been very busy over the last four months, I'm hoping to have more
time in March, hopefully even in February.

I guess I really ought to find the courage to publish my current
version.  For various reasons, though, I don't want to put my CVS tree
on SourceForge.

Regards,

                                        Juliusz

[Dps-devel] moving along

[trevor <two...@ic...>]

hi everyone!

i am happy to report that i can now get the example program from 
chapter 8 (that i mentioned before) to work! which also means i was 
able to compile and install the dps extension.

i was wondering what i should move onto now, suggestions welcome. i was 
thinking of spending the weekend doing more reading (i still have the 
"Client Library Supplement for X", the "pswrap Ref Manual", and the 
"Display Postscript Toolkit for X" to read through). i would also like 
to find the source to "pswrap" and try to figure out why i wants to 
insert the line:

	#include "psops.h"

instead of:

	#include <DPS/psops.h>

into the generated *.c file.

i could also read up more on the Postscript language itself (i've 
worked with it before, but not to the extent required for this project).

maybe i should start reading through the existing dps code? maybe i 
should try to understand the gs code more? maybe i should play around 
more with writing dps applications?

how would one monitor the system's memory (to observe the leaks)? when 
the application terminates is the leaked memory reclaimed or does the X 
server need to be restarted?

this list sure is quiet. is there any development going on "behind this 
list's back" that i should be aware of?

best regards,
	trevor
-- 

http://home.ica.net/~vjbtlw/

[Dps-devel] return values from PSitransform

[trevor <two...@ic...>]

hi everyone!

when i typed in the example program from chapter 8 of the "Client 
Library Referenc Manual" i didn't of course, enter it EXACTLY as in the 
book.

as i played around with it, i couldn't help notice that it was 
necessary to negate the "height" value that is returned from the 
PSitransform() function. but in the example program they don't do 
likewise. how do we know which to follow?

best regards,
	trevor
-- 

http://home.ica.net/~vjbtlw/

Re: [Dps-devel] Building with XFree86 4.0.2?

[Kevin B. <Co...@co...>]

Kevin Brosius wrote:
> 
> 
> Has anyone built dps-0.0.6 with XFree86 4.0.2?  I'm failing the first
> compile with:
> 
> ------------------------------
> 
> making all in ./dpsi...
> make[1]: Entering directory
> `/usr/local/src/dps/dps_gs6.01/dps-0.0.6/dps/dpsi'
> gcc DefaultGcc2i386Opt    -I. -I..

      ^^^^^^^^^^^^^^^^^^

Hmm, this seems to be a problem without default ProjectRoot.  A second
machine with default X install builds fine...

{snip}

> 
> Also, has anyone started using gs 6.50?
> 
> --
> Kevin
>

[Dps-devel] Building with XFree86 4.0.2?

[Kevin B. <Co...@co...>]

Has anyone built dps-0.0.6 with XFree86 4.0.2?  I'm failing the first
compile with:

------------------------------

making all in ./dpsi...
make[1]: Entering directory
`/usr/local/src/dps/dps_gs6.01/dps-0.0.6/dps/dpsi'
gcc DefaultGcc2i386Opt    -I. -I..           
-I/usr/local/src/xc-4.0.1x_kjb_loa
der/xc/programs/Xserver/include
-I/usr/local/src/xc-4.0.1x_kjb_loader/xc/include
            -I/usr/local/src/xc-4.0.1x_kjb_loader/xc/programs/Xserver/mi
    -I/usr/local/src/xc-4.0.1x_kjb_loader/xc/include/extensions
-I/usr/local/src
/xc-4.0.1x_kjb_loader/xc/include/fonts           
-I/usr/local/src/xc-4.0.1x_kjb
_loader/xc/programs/Xserver/hw/xfree86
-I/usr/local/src/xc-4.0.1x_kjb_loader/xc/
programs/Xserver/hw/xfree86/common
-I/usr/local/src/xc-4.0.1x_kjb_loader/xc/prog
rams/Xserver/hw/xfree86/os-support  -I/usr/4.0/X11R6/include   -Dlinux
-D__i386_
_ -D_POSIX_C_SOURCE=199309L -D_POSIX_SOURCE -D_XOPEN_SOURCE
-D_BSD_SOURCE -D_SVI
D_SOURCE    -DSHAPE -DXINPUT -DXKB -DLBX -DXAPPGROUP -DXCSECURITY
-DTOGCUP  -DXF
86BIGFONT -DDPMSExtension  -DPIXPRIV -DPANORAMIX  -DRENDER -DGCCUSESGAS
-DAVOID_
GLYPHBLT -DPIXPRIV -DSINGLEDEPTH -DXFreeXDGA -DXvExtension
-DXFree86LOADER  -DXF
ree86Server -DXF86VIDMODE  -DSMART_SCHEDULE -DBUILDDEBUG
-DX_BYTE_ORDER=X_LITTLE
_ENDIAN -DNDEBUG   -DFUNCPROTO=15 -DNARROWPROTO   
-DGS_LIB_DEFAULT='"/usr/4.0/X
11R6/lib/X11/ghostscript/6.01/lib:/usr/share/ghostscript/fonts"'   
-DEXTMODULE
  -c -o dpsgs.o dpsgs.c
gcc: cannot specify -o with -c or -S and multiple compilations
make[1]: *** [dpsgs.o] Error 1
make[1]: Leaving directory
`/usr/local/src/dps/dps_gs6.01/dps-0.0.6/dps/dpsi'
make: *** [all] Error 2

------------------------------

On second thought maybe this is a gcc problem on my end...  It doesn't
look like there are multiple c files.  Anyone else seen this?

Also, has anyone started using gs 6.50?

--
Kevin

Re: [Dps-devel] Ghostscripts versions?

[Juliusz C. <Jul...@en...>]

Hi Kevin,

KB> I'm about to try out DPS and wondered, are both Ghostscript 6.50 and
KB> 6.01 usable with dps 0.0.6?  

No, you need 6.01.  I am quite positive that the patch will not apply
to 6.50, as dps-0.0.6 includes a number of bug fixes that were
included into GS 6.50.

Regards, and good luck,

                                        Juliusz

[Dps-devel] Ghostscripts versions?

[Kevin B. <kbr...@kn...>]

I'm about to try out DPS and wondered, are both Ghostscript 6.50 and
6.01 usable with dps 0.0.6?  

-- 
Kevin Brosius

[Dps-devel] can't create context

[tlw <two...@ic...>]

i'm really excited about this dps project!

i've been reading through the suggested Adobe DPS documents and came 
across an example program in chapter 8 (page CL-28) of the "Client 
Library Reference Manual". i haven't yet compiled and installed the dps 
Xserver extension, i just wanted to play around with dps and so was 
using the libdps that comes with XFree86 4.0.2, found in /usr/X11R6/lib.

i compiled the example program okay but when i run it, it can't create 
the DPSContext. the call to:

ctxt = XDPSCreateSimpleContext( dpy, xWindow, gc, 0, XWINDOW_HEIGHT, 
DPSDefaultTextBackstop, DPSDefaultErrorProc, NULL );

always fails and returns 0 (i.e. NULL).

looking through the dps library source code (dpsXclient.c), the only 
thing XDPSCreateSimpleContext() does it to call XDPSPrivContext() and 
then call DPSCreateContext(). one of these is failing and i was hoping 
someone might know why.

perhaps i should just compile and install the dps X extension and try 
it with that?

any help would be greatly appreciated

http://home.ica.net/~vjbtlw/

Re: [Dps-devel] just wondering

[Juliusz C. <Jul...@en...>]

Dear Trevor,

TW> i was just wondering how the people involved in this project felt
TW> about C++,

As far as I ken, the project is about combining Ghostscript with
XFree86.  Both are written in plain C, and I really don't see where
C++ fits in.

TW> i've wanted so much to get back to this project

We're looking forward to seeing you around.

TW> i know X traditionally uses imake but i was wondering if there was
TW> any interest in moving to the "auto" tools (autoconfig, automake,
TW> etc...)?

Imake, almost by definition, handles all the platforms that XFree86
does.  DPS will not support any platforms that XFree86 does not.  For
this reason, there is no reason to move to a more general framework
than Imake.

I would like to encourage you at this point to get a working
installation of XFree86 4.0.1+ and DPS.  When you are done, and you're
wondering what to work on, please do get in touch with us again.

Sincere regards,

                                        Juliusz Chroboczek

[Dps-devel] just wondering

[Trevor W. <two...@ic...>]

hi everyone,

this will either be short (and hopefully sweet) or it might rage on for
who knows how long; i'm not really interrested in the latter scenario...

i was just wondering how the people involved in this project felt about
C++, i can't help notice how the words "object oriented" have floated
around before. i haven't thought too much about how it would integrate
but i don't see any problems there.

i'd be happy to work on the port if most people think this is where it
should head, otherwise i'd be happy to work on the port as my own
personal pet project if this isn't where people think this project
should be heading :-)!

about a year ago i was reading the ghostscript documentation and came
across a reference to the fact that someone should be able to take the
sources and create a postscript interpreter library. i searched for a
long time and couldn't find any such library, so i downloaded the code
myself and painstakingly compiled, by hand, enough of the code and
created a main that made postscript-like calls to draw a bezier.

i've wanted so much to get back to this project but because i had the
"guts" working i've left it on the shelf and played with other things.
i can't decide if i'm happy or not to find that this project is already
underway or not!!

anyway, i've got XFree86 4.0.1 working (haven't had time to understand
it yet), i've got the code for 0.0.6, and the ghostscript code for
6.0.1. i'm looking forward to working on this project but i'd like to
spend more time with the existing code to try to get it into my head
first. unfortunately i prefer to understand everything before i make a
move, it means it'll take me longer to get started, but i find it pays
off once i have begun.

i know X traditionally uses imake but i was wondering if there was any
interest in moving to the "auto" tools (autoconfig, automake, etc...)?

best regards,
	trevor

Re: [Dps-devel] GNUstep GUI Bencmarks

[Juliusz C. <Jul...@en...>]

AF> Fill                1.25            0.136           0.170

Bad news.  These are rectangular fills, so they are already as
efficient as can be.  I think the problem is that we're using a
retained window, so we render to a pixmap and then need to
resynchronise before we can copy the pixmap to the window.  A solution
would be to delay the update of the actual window, or to use the NeXT
extensions... which are not implemented yet.

AF> Trans               33.11           5.6             ---(2)
AF> (2) Crashed X11 server

Bad news again.  The glyph cache gets corrupted when we have multiple
contexts.  I think the problem is the same as the one that prevents
the GC from functioning -- incorrect handling of global gstate
objects.

AF> Text                3.36            0.231           1.634

The test uses large glyphs, so the results are somewhat misleading;
I'd like to see a similar test with smaller text (say, 12 pixels).  I
believe that would show more difference between X rendering and the
current free implementations of dps.

                                        J.

Re: [Dps-devel] GNUstep GUI Bencmarks

[Juliusz C. <Jul...@en...>]

CDR> If I can help with extending GSBench in a vertain direction, let me know!

I haven't read the code yet (will do, really!), but off the top of my
head, a test involving ``colorimage'' would be useful.  Both one large
image and plenty of small images, and both at device resolution and
with scaling.

                                        J.

Re: [Dps-devel] GNUstep GUI Bencmarks

[Philippe C.D. R. <ph...@st...>]

On Tue, 01 Aug 2000, Juliusz Chroboczek wrote:
> Dear Adam,
> 
> Thanks for the benchmarks, I'll get a copy of the application, that's
> going to be helpful for further development.

If I can help with extending GSBench in a vertain direction, let me know!

sweet dreams, Phil
-- 
Philippe C.D. Robert
Developer - StudioSendai.com

Re: [Dps-devel] Philosophy: self-contained DPS with event model?

[Juliusz C. <Jul...@en...>]

TR> But it appears that Display Postscript has always existed on top of X,

That's not quite true.  DPS on the NeXT allows manipulation of
windows, although the events are still handled by client code.  And
NeWS, of which you are aware, did allow applications to do all the
user interface in PS code.

Extending DPS to be compatible with NeWS is not a good idea, as NeWS
has a few issues that prevent it from being implemented with a GC
(NeWS used reference counting).  However, a similar design would be
possible.

TR> So maybe NeWS is what I'm looking for, but not much of it is 
TR> available AFAICT, just some documentation (which I haven't read yet).

A very readable introduction is the NeWS Book, which you'll probably be
able to find in most University libraries.

     The NeWS Book, James Gosling, David S. H. Rosenthal and Michelle J.
     Arden. The Sun technical reference library, Springer-Verlag, 1989.

TR> But I have my doubts whether Postscript can scale well
TR> enough in both directions (small enough for limited devices and large
TR> enough for 3D simulation/VR environments).  And I wonder why Postscript
TR> is so arcane... for a long time Adobe had a monopoly; attempts by 
TR> printer mfgrs to clone it were not quite successful... 

PS is actually a pretty simple language.  It's basically a Lisp
dialect that happens to use postfix notation (instead of fully
paranthesised prefix notation) and defers all environment management
to user code.

The issue is the graphic library.  It is absolutely huge, and contains
code for a number of image formats, a number of font formats,
compression and decompression, halftoning, stippling, etc.

TR> and Ghostscript is the only free implementation, and is well known
TR> to be messy code which few can understand well enough to add
TR> features to it.

It's not messy code.  It's very highly object-oriented code that was
written by a person who spent most of his career writing Smalltalk code.

TR> But how is interpreting Postscript fundamentally any harder than
TR> interpreting Scheme or FORTH?

It isn't.  It is basically equivalent to interpreting Scheme, with the
addition of a Forth-like operand stack.

The main difference is that Scheme reads a complete form before it
starts interpreting, while PS interprets tokens as they are parsed.

TR> I didn't realize until today that Postscript required garbage
TR> collection.

That's because PostScript has Lisp semantics, rather than Forth
semantics.  The stack typically contains references to heap-allocated
data, that need to be garbage collected.

Regards,

                                        J.

Re: [Dps-devel] GNUstep GUI Bencmarks

[Juliusz C. <Jul...@en...>]

Dear Adam,

Thanks for the benchmarks, I'll get a copy of the application, that's
going to be helpful for further development.

AF> Line                2.44            0.728           0.921
AF> Curve               -----(1)        0.352           0.425

These could be improved by mapping DPS line segments to X11 line
segments internally.  Unfortunately, I'm not quite clear about the
exact relationship between DPS and X lines (the pixellisation rules
are different).

AF> Fill                1.25            0.136           0.170

This could be improved by mapping DPS fills to X11 trapezoid fills.
Again, the differences in pixellisation rules might be difficult to
deal with.

AF> Trans               33.11           5.6             ---(2)
AF> (2) Crashed X11 server

I'll look into that.


AF> Text                3.36            0.231           1.634

That's actually the easiest to improve; you just need to implement
``copy_mono'' in the DPS driver.  In the case of big-endian machines,
it would be almost as efficient as X11 rendering (the same blitting
code would be used).

Thanks again,

                                        J.

[Dps-devel] GNUstep GUI Bencmarks

[Adam F. <fe...@do...>]

Here are some recent GUI benchmarks I made with the GSBench application
(see UserApps under http://www.gnustep.org). Bigger numbers are faster.
This was on a GNU/Linux PPC (Mac G4) running X11 4.0.0 (accelerated
graphics), GNUstep 0.6.6 prerelease.

				Backend
Test		xgps (Xlib)	xdps (DGS 0.5.5) xdps (DPS 0.0.5)
----		----------	---------------	-----------------
Line		2.44		0.728		0.921
Curve		-----(1)	0.352		0.425
Fill		1.25		0.136		0.170
Trans		33.11		5.6		---(2)
Text		3.36		0.231		1.634
Composite	5.4		----(3)		----(3)
Window		50.66		5.06		196.200

(1) Not implemented
(2) Crashed X11 server
(3) Not implemented properly.

Thanks to to Juliusz Chroboczek for making some great improvements to
the xdps backend (at least a factor of 4 speed improvement and start up
speed).

-- 
Adam Fedor, Digital Optics            | Fudd's law of opposition: Push
fe...@do...  http://www.doc.com     | something hard enough, and it 
fe...@gn...  http://www.gnustep.org | will fall over.

[Dps-devel] Philosophy: self-contained DPS with event model?

[Shawn T. R. <rut...@cx...>]

I've been tossing around the idea of a "metawidget" system for several
months now... a client/server UI system in which controls are 
represented in a device-independent fashion, and the client can render
them in ways appropriate for the device.  At first I thought of using
XML; then I realized that XML is best for purely "descriptive" or
"declarative" data, and a metawidget system would sometimes need to 
provide behavior too (mostly simple navigational behavior... complex
behavior would be done on the server).  Then I thought of something 
similar to Display Postscript.  One advantage is that Postscript is a
complete enough language that behavior could potentially be scripted as
well as appearance, and in fact some entire programs could consist of 
Postscript code.  Another advantage is that there could be multiple
levels of implementation; an application could start by assuming that
the metawidget implementation is already present on the client machine,
but if it is not, then the client could download a default implementation
from the server.  Users could select their preferred implementations.  It
would be like the ultimate replacement for themes and skins, with 
everything customizable (layout, number of dimensions used, even the
concept of windows could be replaced with whatever else may be imagined).
Some implementations might not be GUIs at all.  An interface for the
blind could be built using voice synthesis and recognition and 
Braille devices, with absolutely no modifications to the application;
because applications would only specify metawidgets (which items
can be selected; which commands are available and what are their 
parameters; multiple views and means to select them; and so on),
not the visual presentation, except in cases where there can only
be a visual representation (for example a 2D drawing).

But it appears that Display Postscript has always existed on top of X, 
never alone; and it is missing the event system because X usually provides 
that.  So maybe NeWS is what I'm looking for, but not much of it is 
available AFAICT, just some documentation (which I haven't read yet).  
I also discovered a system called MOVIE which tries to be a superset of 
everything (an OO variety of Postscript, but can also do 3D graphics and 
integrates access to GL, PHIGS, PEX, Motif, OpenLook, etc...)  But this
is an old academic project with no apparent code available, and in any
case is probably too diversified and heavyweight.  The ideal metawidget
system would have a sufficiently lightweight default implementation that
it could run on otherwise worthless machines like 286's and such.  (In
that case the GUI code should be mostly C rather than mostly 
Postscript, and as long as the user didn't try to get too fancy with 
downloading replacement custom themes it would provide acceptable 
performance.)  But I have my doubts whether Postscript can scale well
enough in both directions (small enough for limited devices and large
enough for 3D simulation/VR environments).  And I wonder why Postscript
is so arcane... for a long time Adobe had a monopoly; attempts by 
printer mfgrs to clone it were not quite successful... and Ghostscript
is the only free implementation, and is well known to be messy code
which few can understand well enough to add features to it.  I don't
know how to write an interpreter for PS, and Ghostscript would be 
too intimidating a way to learn.

But how is interpreting Postscript fundamentally any harder than interpreting 
Scheme or FORTH?  There are many free Scheme interpreters available.
I thought of inventing a "Display Scheme" language with the features
of Display Postscript and the syntax of Scheme, and an event model to
boot.  Maybe more programmers would find it approachable too; it seems
few like to write Postscript by hand, but most undergrad CS students
end up learning LISP or Scheme.

Is there anyone here who can expound on the differences between 
interpreting prefix and postfix notation, and whether one is better than
the other for this purpose?

I didn't realize until today that Postscript required garbage collection.
I would think that since most data is stored on the stack, less 
garbage would accumulate than in OO languages, because that which is
pushed onto the stack is eventually popped.  And there is no reference
concept is there?  If you define something in Postscript for later use,
can you be sure that it will no longer be needed at any time before the
program terminates?  You don't hold a reference exactly, you just name
the thing that you are "defining" and then you can access it by name
at any time later.  So maybe this is where garbage comes from, but how
would you know when it's OK to collect it?

-- 
  _______                   Shawn T. Rutledge / KB7PWD  ec...@bi...
 (_  | |_)          http://www.bigfoot.com/~ecloud  kb...@kb...
 __) | | \________________________________________________________________

Re: [Dps-devel] Re: DPS and the Free World

[Adam F. <fe...@do...>]

> How is the alpha buffer implemented?  Client-side or server-side?
> 
> And how do you handle resizing it when the drawable is resized?
> 

It should be in the server. Resizing is taken care of by called
setXgcdrawable (essentially the same as telling ghostscript to draw to a
new window). GNUstep uses gstate objects also, so we have to be careful
to reset the gstate object.

Re: [Dps-devel] Re: DPS and the Free World

[Juliusz C. <Jul...@en...>]

>> Not surprising.  You can't get much better without some server-side
>> hacking.

MY> The biggest good point of dpsnx.agent(dgs) is, it doesn't depend on
MY> any special X server. If you cannot use XFree86 server in some reason,
MY> dgs will be good choice. However if you can use XFree86 server, free
MY> dps extension is much better than dgs because free dps extension is 
MY> faster than dgs.

Not necessarily.  Dgs could very well use an ad hoc rendering
extension if it is present, and revert to (slow) core X rendering when
it is not.  This could give you about the same performance as a
server-side extension on hacked servers while maintaining portability
to legacy servers.

In my opinion, the biggest advantage of dgs is that if it crashes,
your X server doesn't go down in flames.  It will be a long time
before the extension is sufficiently stable for people to want to
include it in their X server.

Regards,

                                        J.

Re: [Dps-devel] Re: DPS and the Free World

[Masatake Y. <mas...@is...>]

> Not surprising.  You can't get much better without some server-side
> hacking.

The biggest good point of dpsnx.agent(dgs) is, it doesn't depend on
any special X server. If you cannot use XFree86 server in some reason,
dgs will be good choice. However if you can use XFree86 server, free
dps extension is much better than dgs because free dps extension is 
faster than dgs.

> I suggest moving this discussion to <dps...@li...>.

I have one comment to gnustep ML.
As a dgs developer, I need more DPS test program.
I'm using only subset of DPS functions during developing gyve.
So I don't have serious problem in dgs now. But if you find 
serious problems during hacking xdps backend, please let me know.
I'm happy if you send me a minimal pswrap code that shows problem:). 
I'll incorporate it to my gtkDPS. 

Re: [Dps-devel] Re: DPS and the Free World

[Masatake Y. <mas...@is...>]

> How is the alpha buffer implemented?  Client-side or server-side?  
...Agent-side. Not X server-side. Not DPS Client-side.

> And how do you handle resizing it when the drawable is resized?

I have not tested yet.

Masatake

[Dps-devel] Re: DPS and the Free World

[Juliusz C. <Jul...@en...>]

MY> Even they are slow, both of DPS implementations have the NeXT 
MY> extensions, I think.  At least, compositerect operator of development
MY> version of dgs(0.6.0alpha) works.

I didn't know that.  Thanks for the update.

How is the alpha buffer implemented?  Client-side or server-side?  And
how do you handle resizing it when the drawable is resized?

The server-side DPS extension does not support the NeXT extensions,
though.

MY> As I said, compositerect is 20 times slower than rectfill.

Not surprising.  You can't get much better without some server-side
hacking.

I suggest moving this discussion to <dps...@li...>.

Regards,

                                        J.

Re: [Dps-devel] Re: ANNOUNCE: DPS-0.0.4

[Juliusz C. <Jul...@en...>]

PD> FYI, I considered adding an internal monitor that would be locked
PD> and unlocked automatically by the interpreter when executing an
PD> oparray.

There are quite a few ways of doing this, actually.  All have
advantages and drawbacks.  It would be good if we could decide on one.

By the way, I believe there's going to be little contention for locks
in practice.  We're not using true concurrency, but instead simulate
concurrency using a fairly large time quantum.  For contention to
happen you need to switch contexts as a lock is held.  This is not
very likely to happen.

The first idea was having a global variable that counts the number of
oparrays we're in (actually a static in interp.c).  We'd simply
disable all scheduling when this variable in non-zero.  In effect,
we'd have a recursive lock for oparrays, and by disabling scheduling
when this lock is held we automatically ensure that there is never any
contention for it.

The advantage of this method is its simplicity -- I've done it, and
it's ten lines of code.  It's also very lightweight: entering an
oparray costs one extra variable assignment.  The tragedy is that we
never run any code during an oparray, not even core X code: if an
oparray loops or for some reason takes forever, we freeze the X
server.

A variant of this solution is to implement a new PS operator

  {...} .atomically

which executes a procedure with time-slicing disabled.  As .atomically
is explicit, using it makes it more likely that we will not err by
putting something that takes too long within it.

The single-context implementation would, of course, redefine
.atomically as exec.

Generalising that, we could put a real recursive lock in the main
interpreter.  It's almost as lightweight, but it becomes pretty
complicated, as it requires duplicating most of the lock machinery in
the main interpreter loop.  And it does have the flaw described below.

We could use the standard PS locking machinery for the global lock.
The standard PS locks are not recursive, so either we must be careful
to ensure that a context doesn't attempt to deadlock with self, or
else implement recursive locks as an extension.

There is a problem however: consider the following scenario.  Context
C grabs the global lock.  It then gets switched out.  The client kills
C using an X request, or the client dies and the context is destroyed.
The scheduler properly releases the lock that C held, thus leaving no
lock and the global heap in an inconsistent state.

I'm trying to think of a solution to this problem, but it seems
tricky, as it requires that a context may survive its creator.  Unless
we find one, I think we will have to satisfy ourselves with
.atomically.  Yuck.

PD> 1) Some oparrays don't need any locking at all (e.g., ]), and
PD>    shouldn't have to pay the monitor overhead.

This is relevant if we decide to implement locks in PS code.

PD> 2) Different oparrays need to lock different structures.  For example,
PD>    defineresource should lock only the resource machinery.

I'm thinking of a single global lock.  As I said, I don't believe in
contention being significant.

Regards,

                                        Juliusz

[Dps-devel] Re: ANNOUNCE: DPS-0.0.4

[L. P. D. <gh...@al...>]

> Note that the support is not quite correct, as a number of global data
> structures are not protected by monitors, and might therefore be corrupted
> by oparrays (GhostScript's pseudo-operators).  Real operators are run
> atomically, so they are not concerned by this problem.  Until I implement
> monitors, there is nothing to do.

FYI, I considered adding an internal monitor that would be locked and
unlocked automatically by the interpreter when executing an oparray.  I
decided against this because:

1) Some oparrays don't need any locking at all (e.g., ]), and shouldn't have
   to pay the monitor overhead.

2) Different oparrays need to lock different structures.  For example,
   defineresource should lock only the resource machinery.

-- 

L. Peter Deutsch            |               Aladdin Enterprises
gh...@al...           | http://www.aladdin.com | 203 Santa Margarita Ave.
+1-650-322-0103 (9-12 M-Th) | fax +1-650-322-1734    | Menlo Park, CA 94025
	The future of software is at http://www.opensource.org

Re: [Dps-devel] Bug fix: empty images hang the interpreter

[Adam F. <fe...@do...>]

Juliusz Chroboczek wrote:
> 
> The following code is supposed to do nothing, but it hangs
> GhostScript.
> 
>   64 64 8 [64 0 0 64 0 0] () false 3 colorimage
> 
> It occurs in GNUstep (why?).  I'm appending a (preliminary pending

It was actually a bug in the image rendering code, which I've fixed.