1. Clip Anomaly:
when a surface .set_clip is called with a rect which have negative width or height,
seems natural that following fills or blits don't touch at all the surface.
But
width<0 --> surface.get_clip().width == surface.get_width()
height<0 --> surface.get_clip().height == surface.get_height()
so if the left,top of the clip area is not too far you get the surface partially
blited/filled.
The attached clip_test.py demoes this.
Use case:
resizing the clip area in a loop can get the last loop iteration with a
degenerated clip rect.
The natural control variable for the loop is not the width.
Expectation on set_clip behavior with negative width was that nothing would write
to the surface, hence garbage in the screen. Because of unexpected, toke some time
to find the problem.
there is any rationale for the current behavior ?
wouldn't be better my expected behavior ?
If the current behavior will be kept, please mention it in the docs for set_clip
and get_clip, and maybe blit / fill
2. Rect anomaly when width or height is negative:
Look at this:
>>> clip_rect = pygame.Rect(1,1,-100,-100)
>>> clip_rect.width
-100
>>> clip_rect.left
1
>>> clip_rect.right
-99
>>>
Its reasonable that a Rect can serve a width<0 ?
Its reasonable that rect.left>rect.right ?
To me, this behavior broke the user expectations. Even if the 1.8.1 docs tells
that "The size values can be programmed to have negative values, but these are
considered illegal Rects for most operations. "
Much better would be: Accept width or height negative, BUT convert to 0 before
store it internally.
With that, the prev interpreter session would look:
>>> clip_rect = pygame.Rect(1,1,-100,-100)
>>> clip_rect.width
0
>>> clip_rect.left
1
>>> clip_rect.right
1
>>>
As a side effect, opers that uses rects like blit, fill, set_clip... don't need to
be extended to the degenerate cases.
comments ?
--
claxo