bug report for XFractint 20.3
Hi, Just thought I'd send in the minor issues I've had so far. None of them are too bad, but in case anyone is interested... 1) I always get a beep at the end of drawing, even with sound=off. (May sound petty, but it really bugs me) 2) If I move the fractal window around the screen, the fractal appears to be recalculated. This could be a problem with a deep zoom. 3) Sometimes the image looks unfinished, as though Fractint never got around to filling in all the blocks when solid-guessing, even when it's beeped and reported the image complete. You can see an example at http://www.bathysphere.org/xf_prob.gif Regards, -- Edwin
On Tuesday 03 February 2004 9:54 pm, Edwin wrote:
Just thought I'd send in the minor issues I've had so far. None of them are too bad, but in case anyone is interested...
1) I always get a beep at the end of drawing, even with sound=off. (May sound petty, but it really bugs me)
Currently, I can't even get a beep. But, yes, that would be irritating. The float/integer version is now available, which unbreaks some stuff. Try it and let me know if it works better.
2) If I move the fractal window around the screen, the fractal appears to be recalculated. This could be a problem with a deep zoom.
Hmm, I don't see this with either version. But I wasn't looking at a deep zoom, either.
3) Sometimes the image looks unfinished, as though Fractint never got around to filling in all the blocks when solid-guessing, even when it's beeped and reported the image complete. You can see an example at http://www.bathysphere.org/xf_prob.gif
I've seen this, but haven't been able to track it down. It looks like a symmetry problem in the cases I've seen. Perhaps an entry in the worklist is getting deleted for some reason. Jonathan
On Tuesday 03 February 2004 9:54 pm, Edwin wrote:
1) I always get a beep at the end of drawing, even with sound=off. (May sound petty, but it really bugs me)
I've fixed this one. Thanks.
2) If I move the fractal window around the screen, the fractal appears to be recalculated. This could be a problem with a deep zoom.
I have no doubt that I made Xfractint do this, but can you give me an example to help me track it down? 8-)) Jonathan
On Sat, 2004-02-07 at 20:09, Jonathan Osuch wrote:
On Tuesday 03 February 2004 9:54 pm, Edwin wrote:
2) If I move the fractal window around the screen, the fractal appears to be recalculated. This could be a problem with a deep zoom.
I have no doubt that I made Xfractint do this, but can you give me an example to help me track it down? 8-))
This *always* happens for me. I just need to move the fractal window around using its title bar & it recalculates every few pixels (I don't need to release the mouse). The comment about deep zoom was just to explain why I thought it was a problem, not when it happens - sorry for the confusion. In case it's relevant, this is on RedHat 8.0 using Gnome & the Metacity window manager. -- Edwin
On Saturday 07 February 2004 11:40 pm, Edwin wrote:
This *always* happens for me. I just need to move the fractal window around using its title bar & it recalculates every few pixels (I don't need to release the mouse). The comment about deep zoom was just to explain why I thought it was a problem, not when it happens - sorry for the confusion.
In case it's relevant, this is on RedHat 8.0 using Gnome & the Metacity window manager.
Hmm, that might be relevant, because it still doesn't happen on my machine. I did run across the problem with incompleted images which does not involve symmetry. The original, which I can't reproduce from the PAR, was odder because the part that wasn't complete was not the complete strip at the bottom, but portions of it. guessing_bug { ; Version 2003 Patchlevel 1 resest=2003 type=barnsleyj1 center-mag=-0.917058/-0.068673/2.366667 params=0.59999999999999998/1.1000000000000001 float=y inside=0 } Jonathan
On Sunday 08 February 2004 7:26 am, Jonathan Osuch wrote:
guessing_bug { ; Version 2003 Patchlevel 1 resest=2003 type=barnsleyj1 center-mag=-0.917058/-0.068673/2.366667 params=0.59999999999999998/1.1000000000000001 float=y inside=0 }
Ach! Try this instead: guessing_bug { ; Xfractint Version 2003 Patchlevel 1 reset=2003 type=barnsleyj1 center-mag=-0.917058/-0.068673/2.366667 params=0.59999999999999998/1.1000000000000001 float=y inside=0 } I tried to edit the name and missed, then didn't type reset back in correctly. I've also added the Fractint/Xfractint to help identify (automatically) which version created the PAR. Jonathan
On Sun, 2004-02-08 at 05:36, Jonathan Osuch wrote:
Ach!
Try this instead:
guessing_bug { ; Xfractint Version 2003 Patchlevel 1 reset=2003 type=barnsleyj1 center-mag=-0.917058/-0.068673/2.366667 params=0.59999999999999998/1.1000000000000001 float=y inside=0 }
I tried to edit the name and missed, then didn't type reset back in correctly. I've also added the Fractint/Xfractint to help identify (automatically) which version created the PAR.
Now I'm even more confused. I thought we were talking about bug #2 ("fractal is recalculated multiple times when the window is moved around"). That doesn't depend on the .PAR file - it's generic. I assume you want me to look at this .PAR in the context of #3 ("sometimes the images doesn't look finished"), right? So, yes, the .par file you included does leave a band of larger squares across the bottom and reproduces #3. Hope that helps! -- Edwin ;
On Sunday 08 February 2004 9:32 am, Edwin wrote:
Now I'm even more confused. I thought we were talking about bug #2 ("fractal is recalculated multiple times when the window is moved around"). That doesn't depend on the .PAR file - it's generic. I assume you want me to look at this .PAR in the context of #3 ("sometimes the images doesn't look finished"), right?
So, yes, the .par file you included does leave a band of larger squares across the bottom and reproduces #3.
Yes, I slipped in a discussion of comment 2. Sorry, it was actually more a comment for Tim. But, it is showing a problem that occurs when the image crosses the x-axis. I played with it by panning around and eventually, it stopped happening. I could reload the PAR and it would work like it always should, with all the pixels generated. With regard to comment 3, are you moving a window with a calculating image or is it done? Jonathan
On Sun, 2004-02-08 at 07:24, Jonathan Osuch wrote:
With regard to comment 3, are you moving a window with a calculating image or is it done?
The image has finished calculating. To speculate wildly about the cause of this, possibly the window manager is generating an event indicating that the window size has changed even though it hasn't - I've had that happen in my programs before. You could try checking to see if the new width & height are really different before recalculating. -- Edwin
On Sunday 08 February 2004 11:17 am, Edwin wrote:
The image has finished calculating.
To speculate wildly about the cause of this, possibly the window manager is generating an event indicating that the window size has changed even though it hasn't - I've had that happen in my programs before. You could try checking to see if the new width & height are really different before recalculating.
We do. It is in the resizeWindow() routine in unixscr.c. But, I may have messed up the select masks, or something else. Jonathan
Jonathan Osuch wrote:
guessing_bug { ; Xfractint Version 2003 Patchlevel 1
I've also added the Fractint/Xfractint to help identify (automatically) which version created the PAR.
So the 'identifier' is now part of the COMMENT= parameters for all future releases?? P.N.L. ------------------------------------------------- http://home.att.net/~Paul.N.Lee/PNL_Fractals.html http://www.Nahee.com/Fractals/
On Sunday 08 February 2004 11:00 am, Paul N. Lee wrote:
So the 'identifier' is now part of the COMMENT= parameters for all future releases??
The 'identifier' as well as the version and patch number only appear when the patch level is not zero. So, official releases will never display it. Other than that, yes, it will always be a part of it. Is that a problem? Jonathan
Jonathan Osuch wrote:
The 'identifier' as well as the version and patch number only appear when the patch level is not zero. So, official releases will never display it. Other than that, yes, it will always be a part of it.
Thanks for the more detailed information. Just thought it would be a nice addition to official releases. Especially if it also showed whether it was a Float-Only, or Integer version (now that there are so many ways that FractInt exists). :-)
Is that a problem?
Not for me. Do you think there might be, should I be looking for one?? Sincerely, P.N.L. ------------------------------------------------- http://home.att.net/~Paul.N.Lee/PNL_Fractals.html http://www.Nahee.com/Fractals/
On Sunday 08 February 2004 1:52 pm, Paul N. Lee wrote:
Thanks for the more detailed information. Just thought it would be a nice addition to official releases. Especially if it also showed whether it was a Float-Only, or Integer version (now that there are so many ways that FractInt exists). :-)
Yes, that's a good idea. I'll think about how I want to implement it. Thanks.
Is that a problem?
Not for me. Do you think there might be, should I be looking for one??
LOL. I mistook the tone of your message. Jonathan
participants (3)
-
Edwin -
Jonathan Osuch -
Paul N. Lee