From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11120 invoked by alias); 4 Dec 2004 05:04:48 -0000 Mailing-List: contact xconq7-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: xconq7-owner@sources.redhat.com Received: (qmail 11100 invoked from network); 4 Dec 2004 05:04:45 -0000 Received: from unknown (HELO edam.execulink.net) (199.166.6.57) by sourceware.org with SMTP; 4 Dec 2004 05:04:45 -0000 Received: from opal.ansuz.sooke.bc.ca (dsl1637.rba1.pppoe.execulink.com [209.213.252.111]) by edam.execulink.net (8.11.6/8.11.6) with ESMTP id iB454ic18263; Sat, 4 Dec 2004 00:04:44 -0500 Date: Sat, 04 Dec 2004 05:23:00 -0000 From: mskala@ansuz.sooke.bc.ca To: xconq7 , xconq-general@lists.sourceforge.net Subject: How long was *that* there, I wonder? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2004/txt/msg01457.txt.bz2 So, after a *lot* of debugging I managed to track down the source of a lot of my problems with the IMF code. You know what it was? set_image_pixel_at. It's a low-level function used throughout the IMF code. It basically just lets you index into bitmaps. I've been seeing calls to it all over the place, and writing some, and skipping over it in the debugger, because I thought it was obvious what it did. You call it with coordinates and a parameter 1 to set a bit, and you call it with coordinates and a parameter 0 to clear a bit. Right? Turns out that it actually does a bitwise OR. So if you try to clear to 0 a bit that's already set to 1, nothing happens. It appears that the code prior to my work on it only ever used set_image_pixel_at when the input happened to have been initialized to all zeroes, so this behaviour worked. My code tries to use it to make changes in already-loaded bitmaps, and then it fails. It appears *intended* to replace the existing value whatever it might be, and that's certainly the behaviour I would like for my own use. I changed it to do that (the function is local to imf.c, so I think any unintended side effects of changing it will be easy to contain) and all of a sudden a whole lot of my own code behaves a whole lot more like what I expected. Now I have to go through and un-do all the elaborate changes I made while I was chasing this bug through other parts of the code. I think I'll include this patch as part of one of my bigger ones rather than trying to submit it independently; although I think the existing code is buggy, the bug doesn't show up except when my code tickles it. I'm not sure of the moral of the story - maybe "It's a good idea to trace down into those low-level functions once in a while". For such a simple bug, this one soaked up a lot of debugging hours. -- Matthew Skala mskala@ansuz.sooke.bc.ca Embrace and defend. http://ansuz.sooke.bc.ca/