Index: [thread] [date] [subject] [author]
  From: Steve Cheng <elmert@ipoline.com>
  To  : ggi-develop@eskimo.com
  Date: Mon, 24 Aug 1998 18:35:51 -0400 (EDT)

Re: debugging libggi...

On Mon, 24 Aug 1998, Marcus Sundberg wrote:

> I'm not sure what you mean here?
> A DirectBuffer is a structure that describes a memory region
> on some hardware. Each structure is initialized by a library
> and needs to be deinitialized by the same library. Therefore
> the libraries need to know which buffers they have allocated,
> in case another library moves them around.
[...]

You misunderstood me.

I'm talking about:

typedef struct {
!!!	int		idtag;
	uint32		type;		/* buffer type */
	int		frame;		/* framenumber (GGI_DB_NORMAL) */
[...]
} ggi_directbuffer;

versus:

typedef struct {
	int                     num;
	ggi_directbuffer        **bufs;
!!!	int                     *idtag;
} ggi_db_list;


In the former case, idtag is associated with the DirectBuffer itself;
In the latter case, idtag is associated with the DirectBuffer's *entry* in
_ggi_db_list.  You proposed the latter case.

In the future where where libggi or its extensions do more interesting
stuff with DirectBuffer, I think the way it is done in the former case is
more useful and convenient.

> ggi_db_list is not a "paranoid encapsulation", it's a way to
> keep track of buffers without having every target implelenting
> the same code.

I meant the putting int *idtag in _ggi_db_list rather than int idtag in
ggi_directbuffer for "app should not see internal tag purposes", when the
other way is easier.

--
Steve Cheng               

email: steve@ggi-project.org   
www: <http://shell.ipoline.com/~elmert/>;

Index: [thread] [date] [subject] [author]