Re: Qahirah: A High-Level Cairo API Binding For Python 3

Olaf Schmidt <[email protected]>
Newsgroups gmane.comp.lib.cairo
Message-ID <[email protected]>
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



-- 
cairo mailing list
[email protected]
http://lists.cairographics.org/mailman/listinfo/cairo
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.