[cairo] understanding _cairo_path_fixed_fill_extents()

[Bill Spitzak]

Usually when code figures out the extents, it also has a side effect of
making sure the points are in a particular order. This is due to it using
min() for one corner and max() for the opposite corner. So I think in this
case it is safe to say the points will be in this order.

Generally most code in Cairo and other places treat negative width/height
as empty rectangles, not inverted ones. In most cases this makes the code
simpler.

On Sat, Dec 19, 2015 at 10:13 AM, Enrico Weigelt, metux IT consult <
enrico.weigelt at gr13.net> wrote:

> On 19.12.2015 11:11, Uli Schlachter wrote:
>
> > I don't really know, but I wonder: Why would the points be the other >
> way around? I guess path->extents.p1 is defined to be the north west
> > corner and it can only be south or east of p2 due to rounding issues
> > somewhere?
>
> It that really the case ? Can we be sure about that ?
> (honestly, I have no idea :()
>
> > So based on a definition of "p1 is the north-west corner", I think this
> function
> > does exactly the right thing. If this every is a problem, the code
> generating
> > this bogus extents should be fixed.
>
> Okay, do have that definition scribed in stone ? If not, should we do
> that ?
>
> I agree that such an definition might be helpful, but there *might* be
> cases where it's turned around. How can we detect those cases (and
> find the responsible code) w/o too much overhead ? Maybe some
> assert()'s.
>
> --mtx
>
> --
> Enrico Weigelt,
> metux IT consulting
> +49-151-27565287
> --
> cairo mailing list
> cairo at cairographics.org
> http://lists.cairographics.org/mailman/listinfo/cairo
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cairographics.org/archives/cairo/attachments/20151221/afa62285/attachment.html>