[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [pygame] BUG?: clip and Rect anomalies when width or height negative

I think pygame could do much better with degenerate/empty rects. This also comes up in the union and unionall methods - it would be nice to be able to have an empty rect that when unioned into another rect yields that other rect. Then you could write something like 

u = Rect((0,0),(0,0))
for r in c:
u.union_ip(r)

or just
Rect((0,0),(0,0)).unionall(c)
The problem right now is that the result will always contain (0,0) even if the rects you are unioning don't. To get the right union right now you need to have much uglier code. 

--Mike


claudio canepa wrote:

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