[Gs-code-review] Implementing Visual Trace service

[Igor V. Melichev]

Peter,

> From: L. Peter Deutsch [mailto:ghost at aladdin.com]
> Sent: Sunday, February 10, 2002 9:51 AM
> To: igor at artifex.com
> Cc: gs-code-review at ghostscript.com
> Subject: Re: [Gs-code-review] Implementing Visual Trace service

Thank you for your comments.

> 3. it would interfere memory management;
>
> You can easily create a completely separate instance of the memory manager
> for the second graphics stack / graphics library instance.

This doesn't solve the problem.
The debug-purpose instance of graphics library allocates memory
blocks, therefore addresses of the debuggee's memory blocks
will be different. They will change frequently if a new trace code
is inserted. The debugging in such environment is ineffective.

> So far, it is 600 lines of code, about equally split between
> platform-dependent and platform-independent.  It introduces a potentially
> major new source of platform dependency into the Ghostscript architecture.
> If dwtrace.[ch] is typical, 300 more lines of code will have to be written
> for the X platform, for the Mac platform, etc., or else vdtrace must be
> removed from the list of platform-independent graphics library files.

The output should appear in the window immediately
after a graphic element is painted, to provide a visualization
of step-by-step execution. Intermediate raster
requires too big efforts for making this fast enough.
Therefore I map graphic elements immediately to Windows API functions.
On other platforms appropriate graphics API to be used.
Therefore the platform-dependent part is being duplicated in any case.
By another hand, we don't need to port it to all platforms,
but to development platforms only.

> I still do not like this idea at all in its present form.

It is not our main development, and there is no time for
developing another big project. I've coded and debugged my one in 1 day.
Then I've spent a lot of time for porting it to current states of the main
branch
each time when the main branch was changed by other developers.
Perhaps the debugging of the filling algorithm and the hinter
was dramatically speeded up.

By another hand, once vd_* interface is defined,
it is possible to replace the implementation later.

Igor.