Re: [GD-DEVEL] Road to 3.0

--000000000000cd627105c76d0aef
Content-Type: text/plain; charset="UTF-8"

On Sat, Jul 17, 2021 at 7:18 PM Pierre Joye <[email protected]> wrote:

> Hi Chris,
>
> Long time :)
>

indeed -- I've done almost nothing with py_gd for years, it meets our needs
as is. But this has revived my interest, so hopefully I'll be able to pick
it up again.


> Both, we also have Gitter chat.
>
> https://gitter.im/libgd/libgd?utm_source=share-link&utm_medium=link&utm_campaign=share-link


Got it.


> > We've found that rending speed correlates almost directly, regardless of
> library, with the number of bytes of the image --
>


> Also the 32bits format is not lineary 4x slower than a single channel
> surface.


no, I don't think it was linear, but interestingly, it scaled far more with
the nuber of bytes in teh image -- eg both the size of the image and number
of bytes per pixel than on the complexity of the drawing. We tend to render
very complex polygons, and the number of vertices made far less
difference to rendering time that size of the image.

Without careful profiling, I concluded that on modern hardware the
bottleneck was not the computation, but pushing the memory around. That was
10+ years ago, so who knows now?

Anyway, the point is that I still want 8 bit images :-)

> Why not adopt (or heavily borrow from) one of the other, more modern
> rendering libs: AGG, Skia, other options? I know I chose libgd because it's
> simple and lightweight (and 8 bit support), but if it's going to grow and
> be modernized, maybe a libgd wrapper / API around existing code makes more
> sense. I'm not so much questioning that decision -- I'm sure you have your
> reasons, but I do think it would be good to write them down so we all know.
>
> This is what I do. I use the Freetype raster and stroker. This is what
> most cairo uses as base as well. Skia is a bit different and kind of
> too complex for GD.


Agree on that.


> I think I explained in the roadmap 3.0 wiki.


I saw the mention of freetype -- funny, I'd never thought that it would be
useful outside of fonts, but of course it is. and the famous tiger example
looks good.


> The
> main reasoning is to keep libGd with as little dependence as possible
> and provide key features out of the box. What do you think?
>

I think that's a worthy goal -- one of the challenges with Cairo is that it
has so much integration. If you wanted to use its renderer, you had to
install the whole thing, and that was a real pain, at least outside of
Linux.

Did you look at AGG? You may not want to deal with C++ (understandable),
but it is actually pretty darn self contained, and AFAIK, has support for
line dashing and the like that freetype may not.

> * The somewhat awkward API for drawing, some things you specify in the
> drawing call, some beforehand -- I'm sure that's a result of growing
> features over the decades, but it will be nice to clean that up.
>
> Yes, old school drawing API. The new one follows the Cairo/Canvas APIs.
>

I've always found that an odd API -- it seems designed for physical
plotters to me "move_to", really?

But is certainly a well used design (and has been around for ages - long
before Cairo -- Apple's QuickDraw, for example)

> * preserving the 8 bit rendering -- is that the plan?
>
> I suppose you mean the current format being actually 31bit? or do you
> refer to the 8 bit palette?
>

I meant the 8 bit palette, no anti-aliasing. I need that not just for
performance and small files, but because I use it to "rasterize" vector
data. For example, I have large polygons defining land, and I want a
land-water mask. eac hpixel can only be land or water, so anti-aliasing
doesn't help.


> Ideas welcome. I try to follow that for the new API (gdSurface or
> gdContext). While I do try to avoid having callback in the struct, but
> maybe that would make the whole thing easier.
>

I'll take a look when I get a chance, if I have any suggestions I'll let
you know.

> A "graphics object" API on top of the classic vector API e.g, things like:
> >
> > gdContextDrawPolygon(coordinates)
>
> I am not sure yet what to do with older APIs. BC is key. So ideas
> welcome! This is indeed easy to implement.
>

Maybe it's too much, but I"m thinking that the old API is kept for backward
compatibility, but maybe a new one that is more one-call-for-a-given shape.
thought that would make 3 APIs which is a bit crazy.

They are usages for both.


Indeed -- having access to the lower level functionality is important, But
it's also nice to make the easy things easy:

As they say, the easy stuff should be easy, and the hard stuff should be
possible.

Starting at the lower level makes a lot of sense.


> That can indeed be added. I do however keep the Cairo/Canvas API as a
> model, which is most likely becoming an ISO standard. It will help
> developers I think.
>

Agreed -- familiar / standard interfaces are a very good thing.

What I am trying to say is you are 200% welcome to
> help, contribute, propose, etc. :)
>

Will do!

-CHB

-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

[email protected]

--000000000000cd627105c76d0aef--