On Sun, 23 Apr 2006, Bob Friesenhahn wrote:
On Sun, 23 Apr 2006, Daniel Reed wrote:typedef struct nscreen_window_t { uint32_t framebuffer[1024][768]; int x, y; } nscreen_window_t;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.
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?
This was a great example since it represents the main bit of configury in my library that needs to be remembered at install time. The type representing 'framebuffer' can be one of three possible sizes and the application is free to update it.
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?
-- Daniel Reed <n@xxxxxx> http://shell.n.ml.org/n/ http://naim.n.ml.org/ "A man that is truly great is he who makes the world his debtor." _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
