[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Solving the config.h nightmare ?

From: Bob Friesenhahn
Subject: Re: Solving the config.h nightmare ?
Date: Sun, 23 Apr 2006 21:48:18 -0500 (CDT)

On Sun, 23 Apr 2006, Daniel Reed wrote:

Your example seems to assume that the client app will not be manipulating 'framebuffer directly'.

That can be done through an API call, to do whatever is necessary to get the buffer from the ncurses WINDOW, GLX Window, or the dummy .framebuffer.

Gaining access to a buffer is not hard. Updating the buffer reliably is more difficult.

If it does (for performance reasons), then it needs to know that framebuffer is an array of uint32_t with a particular size.

Is your issue that the buffer might be a uint32_t array sometimes and something else other times, and that needs to be communicated, or that the API uses the type uint32_t but that type (under that name) isn't guaranteed to always be usable?

The former.

When is the format for the buffer set, at GraphicsMagick ship time, GraphicsMagick build time, dependent program ship time, dependent program build time, or dependent program run time?

In this case, at GraphicsMagick build time. Certainly the design can be improved, but my point was that sometimes it is useful for the dependent application to share access with the library to a data with a pre-arranged format. Other design approaches add abstraction, but they usually add a bit of run-time overhead as well. Some configuration options do need to be remembered by the installed header files.

Bob Friesenhahn
GraphicsMagick Maintainer,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]