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

From: Mika Heiskanen (Mika.Heiskanen_at_[hidden])
Date: 2002-05-06 00:49:31

Joel de Guzman wrote:

> I agree with most of what you said. However, you are implying that
> standard libraries should not use platform specific APIs. This is
> certainly not true. As an example, how do you think are standard
> files and streams implemented anyway? Ultimately, it should map
> to the underlying platform where it is deployed. The key point here
> is that these calls are opaque and hidden from the client. The cross-
> platform API shields the client from the platform.

There has probably been poor wording by me. I am specifically opposed to a 
standard library which would may 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. Attempting 
to standardize the copying call itself is most likely a useless attempt, 
it would probably force the user to make platform specific proxy classes
anyway.

My understanding is that requiring support for various platforms such as 
Mac, Win and Unix implies supporting such copying to the screen. I do not 
think it is the responsibility of the 2D rendering library itself. 
However, should someone build a library on top of the 2D rendering library 
to handle such platform dependencies is a completely different thing. I am 
thoroughly for such a library. However, I do not its place is in the 
standard C++ library, not unless the library would also support windows, 
widgets and so on. I do not believe that will happen any time soon.

Maxim Shemanarev wrote:

> > A singleton registry for registering various image formats such
> > as png, jpeg and gif for both import, export and import type
> > matching purposes.
> [snip]
>
> Well, IMO it should be a separate library/concept.

My reasoning for this is that in my opinion an image object should have 
import and export methods. However I am not completely against placing 
them in a separate ImageIO class. Also needed are generic image format 
attribute containers for storing desired compression level, image quality, 
gamma correction, rendering intent, 'colour palette intent', colour space 
intent (rgba, rgb, grey, bw) and so on. Each image format implementation 
would then use those attributes on i/o which are supported by the image 
format itself.

Such file I/O can be placed in a separate library, along with support for 
platform specific display drivers.

> For example, one of your suggestions is the ability to render a polyline
> with different kinds of joins - miter, round, beveled. Fine, I agree, I
> accept it, and it's not implemented in AGG yet (there's only beveled 
> join). But what if you need your own type of join, say, "flowered" one? 
> The only way to do this is to calculate your own polygon "manually" and 
> to ask Graphics object to render it. Here the information about your
> initial polyline is lost.

But couldn't linecap and linejoin be implemented as policies for the 
method which converts a polyline into a polygon? The user is then free to 
combine any styles and add new ones.

Also, add dash styles to the list of polyline attributes. My  
understanding is that SVG working group is also considering user 
customizable *2D line styles*, which would enable easy rendering of for 
example GIS polylines in more familiar styles than plain dashed lines. 
For example, an alternating red and white pattern with a black outline
can be used for railroads. How this is to be done, I'm not sure. However, 
I am certain SVG would provide the exact mathematical definition for how 
to do it. As such, I believe a 2D rendering engine should then support 
such a method, perhaps by appending a new policy to the argument lists.

> You can ask the Graphics object to render a polyline of a certain width. 
> Good. Then you want to apply affine transformations, say, scaling. What 
> will happen to the width of the polyline? It depends on the order in 
> which calcualtions inside the Graphics object are performed. What is
> first - calculation of the outline or affine transformations? The result
> will depend on this order. When calculation of the outline is performed
> first, the visual thickness will change with changing the scale, otherways
> it will remain the same. if the scaling coefficients are different by X
> and Y the order becomes even more important. In real life there're both
> cases are needed.

IMO the inability to specify absolute sizes for some graphics attributes 
is one of the failures of the current SVG standard. My understanding is 
that such features were omitted by the request of vendors due to being
too difficult to do at that time. However, the working group is sure to
address the issue in forthcoming versions of the standard.

The issue of in which order to apply the affine transformation and the 
expansion into a polygon would then be determined by the unit for the
line width, whether it is absolute or relative.

As you explain, the user must be able to choose the order of the 
transformations to get the desired effect in different circumstances.
At the imperative rendering level of your library this is a bit easier, 
you simply choose the order of the 'pipelines'. Once a general rendering 
model as in SVG comes into play, things get a bit more complicated.
Given that you support both orders, this is not of your concern, but 
the person who would implement a SVG renderer on top of AGG.

--> Mika.Heiskanen_at_[hidden]