GNOME Bugzilla – Bug 161040
dia: the grid is destroyed when drawing an object at zoom level
Last modified: 2005-10-08 20:24:00 UTC
A Debian user reported the following: ================================================================================= The grid goes fubar when drawing objects, some part of the grid get shifted on the left/right/top/bottom depending on the moment. To reproduce, launch dia, leave all default settings, zoom at 400% then draw a simple line. Leave the button pressed and watch the grid shift near the start of your line. Drag the mouse around, and the grid will shift under your mouse. ================================================================================= See also http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=284329 (there's also an example screenshot)
I'd say 'extremly annoying' is quite strong wording for a cosmetical issue, but noticed this myself - and plan to eventually fix it (pathes accepted;) BTW: is it for sure this is with dia-0.94 or does only HEAD does have the problem?
That's why I didn't quote the "extremely annoying". :) I only checked with 0.94.
Created attachment 34948 [details] [review] Patch to fix grid drawing when update rectangle has negative coordinates I believe this patch should fix the issue. The problem arises because of the behaviour of C's % operator when presented with a negative numerator. This of course happens fairly regularly (whenever the update rectangle has a negative coordinate). The fix is simply to make the number positive in such a way that it does not affect the modulo calculation. Apparently, C99 better specifies the behaviour of the % operator under these circumstances, but that was just from a random Google hit rather than any real research on my part. The patch is against 0.94, app/grid.c . It's trivial enough that if it doesn't apply to CVS head you can just merge in the code by hand.
Adding PATCH keyword
I wonder what the major_lines factor is good for.
That's to say how far apart the "thicker" grid lines are, in terms of number of grid lines.
Of course, but why is it used as a factor in the case of negative major_count?
In the patch? A very good question.
Think about it in terms of the maths and the modulo arithmetic; we have a number P such that P < 0, and we want to find a number Q such that Q >= 0, but (P % major_count) == (Q % major_count). To do this, we say Q = P - (P * major_count), which is guaranteed to give a correct answer if major_count > 0 (since the addition of anf multiple of major_count won't alter the modulo).
Thanks, sounds reasonable. :) Maybe these lines should be added as comments into the code (and a possibly a note why we do it).
Thank you for an insightful patch. It has been applied to CVS and the explanation added as a comment.
Adjusting target to help finding 0.94 dups already fixed