Re: [boost] RE: A preliminary proposal: AGG project

From: Mika Heiskanen (Mika.Heiskanen_at_[hidden])
Date: 2002-05-07 00:10:32

Mika Heiskanen wrote:

> There has probably been poor wording by me. I am specifically opposed to
> a standard library which would may [ed note: should have been 'forward']
> line, polygon etc rendering requests to some platform specific API,
> whether it is hardware or software. All rendering should by done by the
> library itself. It is the users responsibility to then copy the pixel
> buffer to a display. By allowing the user to configure the representation
> of the pixel buffer the copying may then involve a direct memcpy via some
> platform specific call.

Beman Dawes followed:

> Please understand that standard library proposals today can't be just 
> "good ideas".  They have to be shown to work in practical computing 
> environments.
>
> Thus for the standard committee to accept a library that leaves some
> responsibility to the user (like copying the pixel buffer to a display), 
> it would have to be shown that this is something a potential user can 
> easily and efficiently do, and the best way to demonstrate this is by 
> proving demonstration code for actual operating systems and graphics 
> packages.
>
> So even if the core proposal itself is not concerned with interfaces to
> common operating systems or graphics packages, practical examples and 
> tests should allow display on common platforms, IMO.

There is nothing contradictory in your and my texts. Given that I followed 
my original quote with how I was /for/ the idea of implementing an 
additional library to perform both file and display I/O functions, we seem 
to agree completely. The I/O implementation library would serve as proof 
of concept, but not be a part of the standard library itself.

The confusion has then probably been over whether to use platform specific 
vector graphics rendering APIs, which I'm against, and whether to use 
platform specific display APIs, which of course is a must in an actual 
interactive application.

Still, regarding the idea of using an external I/O library, any thoughts 
on whether the standard committee would like to standardize the 
*interfaces* of both file I/O and display I/O methods?

--> Mika.Heiskanen_at_[hidden]
    Finnish Meteorological Institute