Re: [GD-DEVEL] Road to 3.0

Hi Crhis,

Long time :)

On Sun, Jul 18, 2021 at 12:51 AM Chris Barker <[email protected]> wrote=
:
>
> This is great news! Thanks for working on this.
>
> Is this list the best place for discussion? Or maybe a label to use on gi=
tHub issues for particular topics?

Both, we also have Gitter chat.
https://gitter.im/libgd/libgd?utm_source=3Dshare-link&utm_medium=3Dlink&utm=
_campaign=3Dshare-link

>
> A bit of background on me:
>
> I'm the author of py_gd, an (incomplete) Object Oriented Python wrapper a=
round libgd.
>
> https://github.com/NOAA-ORR-ERD/py_gd

Great work :)

> Motivations:
>
> Why a new Python wrapper? (note: I wrote it 10 yrs ago, things have certa=
inly changed since then)
>
> * There was no Python lib for doing this kind of drawing that was self-co=
ntained -- There are a few that are embedded in other projects, like Matplo=
tlib (which used AGG), and the PIL, which is kinda incomplete,  but nothing=
 simple and stand alone. (that may have changed, it's been a while :-) )
>
> * We looked at other C / C++ rendering libs, including AGG and Skia. But =
they were complex and hard to build, and crucially, they only support 32bit=
 color. We've found that rending speed correlates almost directly, regardle=
ss of library, with the number of bytes of the image -- so an 8 bit image i=
s four times faster to render than a 32 bit one, all else being equal. And =
that made more difference than the code or the algorithm, even with anti-al=
iasing, though non-anti-aliasing rendering is faster, so another plus for l=
ibGD. We also need plain non-anti-aliased 8 bit rendering for some of our u=
se cases.

The drawing API will support the following formats:
ARGB32
RGB32
A8 (8bit surface singel channel)

Also the 32bits format is not lineary 4x slower than a single channel
surface. It is not the priority now, but SIMD or SSE2+ can process 4
pixels (or 32 single channel pixels) in one operation, which should
help.

> * there was an existing Python wrapper for libgd, but it's:
>  1. written in raw C, using the Python C API, which is really painful to =
write and maintain correctly.
>  2. Is a pretty direct mapping of the libGD API, which is, shall we say, =
not the least bit "Pythonic"

That makes a lot of sense, binding should match the language. :)
> First the big one:
>
> Why not adopt (or heavily borrow from) one of the other, more modern rend=
ering libs: AGG, Skia, other options? I know I chose libgd because it's sim=
ple and lightweight (and 8 bit support), but if it's going to grow and be m=
odernized, maybe a libgd wrapper / API around existing code makes more sens=
e. I'm not so much questioning that decision -- I'm sure you have your reas=
ons, 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. I think I explained in the roadmap 3.0 wiki. 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?

>
> Issues I struggled with with libgd, that I think are being addressed here=
:
>
> * The non-contiguous data storage for images -- I had to copy images to/f=
rom numpy array data blocks, which is really unfortunate -- so YES! That wi=
ll be a great improvement.

Indeed! This is the number 1 pain right now :).

>
> * Missing features such as splines -- that will be great

Done :)

> * The somewhat awkward API for drawing, some things you specify in the dr=
awing 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.

>
> A few thoughts that I didn't see in the notes for 3.0 plans:
>
> * modernize to C sized integer types -- that would be nice.

Yes. Big huge yes.

> * 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?

> Some ideas:
>
> Consider a more object-oriented API? That can be done in C, not with full=
y OOP inheritance and all that, but more namespacing -- and Image with meth=
ods, rather than a huge pile of gd* functions. I've never actually written =
code like that, so maybe not a good idea, maybe I'm just too much of a Pyth=
onista.

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.


> 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.

> Rather than having to loop through a bunch of LineTo calls.

They are usages for both. A chart f.e. will likely use the individual
calls for clean rendering (think path clipping, overlay, stroke and
fill, etc.).

>
> You need those low level APIs for the more complex things, but it's reall=
y nice to have an easy and intuitive way to simply draw basic shapes. I'll =
probably write Python wrappers for that kind of thing anyway, but having it=
 built in would be nice.
>
> Another step higher is to have all the properties of the object to be dra=
wn settable in one call: the line style and width, fill style, colors, etc.=
 That may be too high level an API for this, but it is really nice. Again, =
that's what my Python wrappers provide anyway.

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.

>
> (BTW -- I just looked at the py_gd repo -- and the docs are quite broken =
-- I'll go fix that soon)
>
> Finally, an offer:
>
> I know libgd is very connected to the PHP community, but if you'd be inte=
rested in more tightly coupling development of libgd with py_gd, I'd be int=
erested -- that would allow us to use Python as a testing and demo environm=
ent. If not, I'm happy to keep it as a fully downstream project.

We use PHP MLs and PHP bundles libgd. PHP also represents roughly 60%
of the users. That being said, we do want a larger audience, users and
contributors. I do keep talking to developers using libgd in embedded
devices or IOT. They have radically different needs and slowly match
with what web needs (small, self contained, less dependencies, f.e.
for lambda usages). What I am trying to say is you are 200% welcome to
help, contribute, propose, etc. :)

Best,
--=20
Pierre

@pierrejoye | http://www.libgd.org