Re: [GD-DEVEL] Road to 3.0

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

This is great news! Thanks for working on this.

Is this list the best place for discussion? Or maybe a label to use on
gitHub issues for particular topics?

A bit of background on me:

I'm the author of py_gd, an (incomplete) Object Oriented Python wrapper
around libgd.

https://github.com/NOAA-ORR-ERD/py_gd

Motivations:

Why a new Python wrapper? (note: I wrote it 10 yrs ago, things have
certainly changed since then)

* There was no Python lib for doing this kind of drawing that was
self-contained -- There are a few that are embedded in other projects, like
Matplotlib (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,
regardless of library, with the number of bytes of the image -- so an 8 bit
image is 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-aliasing, though non-anti-aliasing rendering is faster, so
another plus for libGD. We also need plain non-anti-aliased 8 bit rendering
for some of our use cases.

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

So the result is a Python wrapper that provides a "Pythonic" Object
oriented API, written in Cython, which auto-generates C code to call C
libs, doing all the Python-types to C type conversion for you, while also
allowing you to write small bits in Python that compile to C code easily.
py_gd also makes native use of numpy arrays to pass data (both point
coordinates and images) between Python and C, which has substantial
performance benefits.

Anyway, a few thoughts, coming from that background.

First the big one:

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.

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/from numpy array data blocks, which is really unfortunate -- so YES!
That will be a great improvement.

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

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

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.
* preserving the 8 bit rendering -- is that the plan?

Some ideas:

Consider a more object-oriented API? That can be done in C, not with fully
OOP inheritance and all that, but more namespacing -- and Image with
methods, 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 Pythonista.

A "graphics object" API on top of the classic vector API e.g, things like:

gdContextDrawPolygon(coordinates)

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

You need those low level APIs for the more complex things, but it's really
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 drawn
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.

(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
interested in more tightly coupling development of libgd with py_gd, I'd be
interested -- that would allow us to use Python as a testing and demo
environment. If not, I'm happy to keep it as a fully downstream project.

Thanks for all the good work!

-CHB


On Fri, Jul 16, 2021 at 10:19 PM Pierre Joye <[email protected]> wrote:

> Hello GD devs and users,
>
> I hope you are doing well in this weird and difficult time!
>
> As you may have noticed, I have started a new branch to bring libgd to
> the next level. It is in the early stage, however there are already a
> few things to play with.
>
>
> I am trying to summarize it here
> https://github.com/libgd/libgd/wiki/3.0-Roadmap
> The branch is https://github.com/libgd/libgd/tree/features/surface
>
> I would like to know what you would like to see added, ideas, suggestions,
> etc.
>
> The key new features I am looking for are:
>
> - True ARGB/xRGB 32bit
> - Vector based 2D Drawing API
>   - High quality 2D drawing functions
>   - Path and render
>   -  Progress:
> https://github.com/libgd/libgd/wiki/GD-Draw,-vector-based-drawing-APIs
> - Better error handling (less void functions where a status should be used)
>
> I am focusing now on the vector API implementation and the image
> coder/decoder for the ARGB format. Once done, I will start to work on
> the other areas.
>
> All image manipulations (filters etc) will support the new internal
> formats.
>
> The current drawing functions (imageline, polygons, etc)  are unclear.
> We could provide wrapper but applications relying on pixel exact, or
> color exact pixels at specific locations may not like it. What do you
> think?
>
> Suggestions, PRs, tests, etc. are more than welcome!
>
> Best,
> --
> Pierre
>
> @pierrejoye | http://www.libgd.org
>
> --
> GD Devel Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

-- 

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]

--000000000000c1933a05c755596d--