[cairo] Qahirah: A High-Level Cairo API Binding For Python 3

[Olaf Schmidt]

Am 11.03.2015 um 08:33 schrieb Lawrence D'Oliveiro:

> I see a number of limitations. You hard code the size of the pattern,
> rather than deriving it from the size of the design elements.

Well, that's what the Zoom-Argument is for.
At Zoom = 1 a clipped PushGroup of size 60x52 is created.
At Zoom = 2->120x104, at Zoom = 0.5->30x26 appropriately

As I see it, the temp-surfaces you create (to render your Wing-Shape-
Patterns on) are roughly the same size finally (87x150).

Here's two examples for a TriWing in smaller sizes:
http://vbRichClient.com/Downloads/TriWing_Zoom0.75.png
http://vbRichClient.com/Downloads/TriWing_Zoom0.5.png

Below that, as e.g.:
http://vbRichClient.com/Downloads/TriWing_Zoom0.25.png
...the nice shapes are not really recognizable anymore...

> Then I see things like
>
>    For j = 0 To 3: For i = 0 To 3 + j
>
> So you have to make 22 separate copies of the pattern in order to
> ensure there are no gaps. A bit excessive, don’t you think?

Doesn't really hurt, since the rendering happens against a (clipped)
PushedGroup - and cairo is intelligent enough, to not waste too
much time with Path-Renderings outside the clipping-region -
I've just played it safe there...

Just measured the timing for the construction of such a winged
pattern with Zoom=1 - and it comes out with roughly 0.5msec -
and since such patterns are usually created once (at startup),
stored in a dictionary, that's not really a time-critical thing.

> My code is more general than yours.

As said, you obviously missed the Zoom-Factor in my routines.
But feel free to come up with an example, where my implementation
would choke (in your opinion).

>> - is more near the cairo-base-API (and thus nearly 1:1 portable to C)
>
> Which is something I thought I made clear I was trying to get away from.

Not sure what you're trying to "get away from", when working near the
cairo-API causes smaller, easier to understand code (for most of us).

Your Vector- and Matrix-code is surely useful in certain-scenarios -
but (IMO) this Alhambra-like-Pattern-creation is not really one of them.

>> The last point above I've made, since your latest Alhambra-Tiles-
>> Revision is producing artefacts with certain angle-arguments...
>> Here's the PNG-output, your revised Python-code produced:
>> http://vbRichClient.com/Downloads/alhambra_tiles2.py.png
>> ...please have a look at the two last images in the Top-Row.
>
> I think you are looking at a version which is already several hours old.

Just downloaded your latest version - and you're right - the artefact
is gone now, sorry for the noise.

> You *did* see this in the README, did you not:
>
> 	**WARNING:** This Python binding is still to be considered in a
> 	state of flux for now, subject to whatever reorganization looks
> 	to be necessary as experience is gained with using it.
>

No - didn't study the ReadMe, because I had no real intention to use
the wrapper anytime soon.

Your opener-post read a bit like an "official: it's-ready-announcement".

Olaf