I think I was wrong ... I don't remember what I was thinking. :) Anyway, the next major version of pygame already has sdl_gfx integrated I think, so this might be moot. :(
On Sun, Nov 9, 2008 at 5:57 AM, Lorenz Quack <[EMAIL PROTECTED]> wrote: > Hi Forrest, > > sorry for being silent so long. > Anyway, I don't think that my version creates a memory leak. And if it does > then so does the original version, IMHO. > The way I see it the PyArg_ParseTuple doesn't INCREF the refcount on any of > the parameters so there is no need to DECREF on either "points" nor its > content. > The only things that need to be DECREFed are the "x-/ylist" and the > individual "item" extracted from "points" via PySequence_GetItem which > returns a new Reference > according to the docs (http://docs.python.org/c-api/sequence.html) and I do > that if there is an error before returning the exception. > > If I'm missing something about the refcounting and I DO have a memory leak > then doesn't the same memory leak apply to the original implementation in > case the very first > point isn't a sequence of two ints (which is for some reason special-cased)? > > yours > //Lorenz > > > Forrest Voight wrote: >> If there's an error, points past the bad point aren't deref'd. >> >> On Thu, Oct 30, 2008 at 7:24 AM, <[EMAIL PROTECTED]> wrote: >>> Hi Forrest, >>> >>> could you tell me how exactly my version leaks and which variable is >>> leaking? I don't see it. >>> >>> I also think that vert/horiz lines could be dropped. >>> >>> //Lorenz >>> >>> >>> >>> On Mon, 27 Oct 2008 23:03:32 -0400, "Forrest Voight" <[EMAIL PROTECTED]> >>> wrote: >>>> Lorenz: the polygon function is almost a direct copy from draw.c and >>>> your way creates a memory leak if there is an error in a point past >>>> the first one. >>>> >>>> I think we should just remove the vert/horiz lines... just use line. >>>> >>>> On Mon, Oct 27, 2008 at 10:21 AM, James Hancock <[EMAIL PROTECTED]> >>>> wrote: >>>>> A year(or two) ago I found sdl-gfx when I was trying to find ways to get >>>>> anti-aliased circles( I worked on GASP, a beginners game creating api). >>>> My >>>>> understanding then was sdl-gfx was licensed GPL so pygame could not use >>>> it. >>>>> I just checked and now it is LGPL. Yay :) >>>>> >>>>> http://www.ferzkopp.net/joomla/content/view/19/14/ >>>>> >>>>> I talked with Andreas back than and it seemed like he was willing to >>>> help >>>>> the pygame community with integration and possible future work. His >>>> email is >>>>> on the site mentioned above. I would love to see pygame take advantage >>>> of >>>>> some of his work. Good luck, It looks like the ball is already started >>>> on >>>>> this one so lets keep moving forward >>>>> >>>>> Cheers! >>>>> James Hancock >>>>> >>>>> >>>>> >>>>> On Sun, Oct 26, 2008 at 4:34 PM, Lenard Lindstrom <[EMAIL PROTECTED]> >>>> wrote: >>>>>> Here are some more suggestions for the horizontal_line/vertical_line >>>>>> issue. Since they take integer positions I can think of two >>>> alternatives to >>>>>> "(surface, (x1, x2), y, color) and (surface, x, (y1, y2), color)". The >>>> first >>>>>> is to have no horizontal_line and vertical_line. Hide the the calls to >>>> the >>>>>> hlineRGBA and vlineRGBA gfx functions in the generic line function. A >>>> few >>>>>> extra tests to determine if a line is horizontal or vertical probably >>>> won't >>>>>> add much additional overhead to a Python function call. The other >>>>>> alternative is to use a start, length approach: (surface, (x1, y1), >>>> length, >>>>>> color). The length can be negative. This keeps the signature consistent >>>> for >>>>>> both the horizontal and vertical line functions. >>>>>> >>>>>> Lenard >>>>>> >>>>>> Lorenz Quack wrote: >>>>>>> Thanks a lot! >>>>>>> >>>>>>> I just looked through your patch and I have some remarks: >>>>>>> >>>>>>> >>>>>> [snip] >>>>>>> 2) you grouped the arguments to horizontal and vertical line like >>>> this: >>>>>>> (surface, (x1, x2), y, color) and (surface, x, (y1, y2), color) >>>>>>> respectively >>>>>>> I find this grouping not very intuitive. normally we group a pair of x >>>>>>> and y >>>>>>> coordinates which makes sense because they represent one point but I >>>>>>> can't see >>>>>>> such an interpretation here. one could argue to group them (surface, >>>> (x1, >>>>>>> y), >>>>>>> x2, color) but that looks strange as well so I would suggest to not >>>> group >>>>>>> them >>>>>>> at all >>>>>>> >>>>>>> >>>>>> [snip] >>>>>>> Forrest Voight wrote: >>>>>>> >>>>>>>> Hi! >>>>>>>> >>>>>>>> I'm posting the patch at http://im.forre.st/pygame-sdl_gfx.diff , so >>>>>>>> that won't happen again. >>>>>>>> >>>>>>>> It's pretty much a full binding of the shape drawing functions, but >>>>>>>> there's some other stuff in SDL_gfx. >>>>>>>> >>>>>>>> >>>>>> >>>>>> -- >>>>>> Lenard Lindstrom >>>>>> <[EMAIL PROTECTED]> >>>>>> >>>>> >>> > >
