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]