[Gs-code-review] Implementing Visual Trace service

L. Peter Deutsch ghost at aladdin.com
Sun Feb 10 07:44:33 PST 2002

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

I don't understand why.  Is it because you often use breakpoints that are
conditional on a pointer having a particular, specific value?

How can you know that the platform graphics library won't call malloc?
Xlib certainly may.

Also, on some platforms (I don't know whether this happens with MSVC on
Windows), allocation of dynamic storage starts just above the code.  If you
change the size of the code, the addresses of dynamically allocated blocks

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

There is no requirement that a device implementation use an intermediate
raster.  At least one of the Windows drivers doesn't.

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

Not if you use the already existing platform window device.

> By another hand, we don't need to port it to all platforms, but to
> development platforms only.

I agree.  That means at least Windows, Linux, Solaris, and Mac.

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

I've made all the arguments I want to make.  But I still strongly oppose
including vdtrace.c in the list of platform-independent files that are part
of the graphics library, if there is only a Windows implementation and there
are no actual plans to produce implementations for the other development

> It appears that I've missed the most important argument.
> Suppose I need to rewrite GS path construction implementation.  Debugging
> the new one, I need to paint the path in Visual Trace window.  If the
> painting is done with same code (which may be buggy), I can't get an
> useful visualization.
> Same about the filling algorithm - the graphics library uses it for
> drawing lines. Right now I significantly modify the filling algorithm for
> the bug [ #510808 ] Missing vertical stem in 'k'.
> Therefore I believe that the visualization code must be absolutely
> independent on the debuggee, i.e. on the graphics library implementation.

OK, that's a good argument.  So I have a second suggestion.  Make vdtrace.c
use the device interface to call the existing (or new) window devices,
rather than creating a second, parallel set of procedures to invoke the
platform API.  If the device implementations are too slow, improve them,
instead of writing hundreds of lines of code that duplicates function and
has to be propagated to multiple platforms.

For example, the present vd_ interface has moveto, lineto, etc.  I don't
know whether this matches the Windows, X, Mac, ... APIs directly, but I
would be surprised if it did, and even if it does, those procedures
certainly perform mallocs (see the point about memory allocation above).
But there is already a driver API procedure to fill or stroke a path with a
color, and there are already procedures to allocate and deallocate paths.
Why not use them?


L. Peter Deutsch     |    Aladdin Enterprises   |  203 Santa Margarita Ave.
ghost at aladdin.com    |  http://www.aladdin.com  |  Menlo Park, CA 94025

	The future of software is at http://www.opensource.org

More information about the gs-code-review mailing list