{"thread":{"id":"3905","subject":"[BUG] gitk draws a wrong line","startedAt":"2006-04-18T10:40:14Z","lastAt":"2006-04-25T07:54:29Z","messageCount":3,"participants":["Uwe Zeisberger","Paul Mackerras"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"18800","messageId":"20060418104014.GA2299@informatik.uni-freiburg.de","threadId":"3905","inReplyTo":null,"subject":"[BUG] gitk draws a wrong line","fromName":"Uwe Zeisberger","fromEmail":"zeisberg@informatik.uni-freiburg.de","sentAt":"2006-04-18T10:40:14Z","receivedAt":"2006-04-18T10:40:14Z","isPatch":false,"sender":{"key":"u.kleine-koenig@pengutronix.de","avatar":"https://gravatar.com/avatar/354b5e3ceb2806a2f1e1e382ac29ddbdad18288654da62b61eb13583a857eee7?d=mp&s=160"},"body":"Hallo,\n\nI'm using 1.3.0.rc4.g2855d in Linus Linux tree. When doing\n\n\t$ gitk v2.6.16..v2.6.17-rc1\n\nand then going to commit 10c2df65060e1ab57b2f75e0749de0ee9b8f4810, \nI see a small superfluous line between the two commits under 10c2df.\n\nBut still worse, if I select the line going down from 10c2df and then\nselect it's parent (i.e c76b6b) I get a big line ending in the commit\ndescriptions and four lines ending in midair.\n\nSee screenshots at \n\n\thttp://www.informatik.uni-freiburg.de/~zeisberg/bug-gitk/\n\nBest regards\nUwe\n\n-- \nUwe Zeisberger\n\ncat /*dev/null; echo 'Hello World!';\ncat > /dev/null <<*/ \n() { } int main() { printf(\"Hello World!\\n\");}\n/* */\n"},{"id":"19068","messageId":"17485.31716.452326.229628@cargo.ozlabs.ibm.com","threadId":"3905","inReplyTo":"20060418104014.GA2299@informatik.uni-freiburg.de","subject":"Re: [BUG] gitk draws a wrong line","fromName":"Paul Mackerras","fromEmail":"paulus@samba.org","sentAt":"2006-04-25T01:31:16Z","receivedAt":"2006-04-25T01:31:16Z","isPatch":false,"sender":{"key":"paulus@samba.org","avatar":"https://avatars.githubusercontent.com/u/1606439?v=4"},"body":"Uwe Zeisberger writes:\n\n> and then going to commit 10c2df65060e1ab57b2f75e0749de0ee9b8f4810, \n> I see a small superfluous line between the two commits under 10c2df.\n> \n> But still worse, if I select the line going down from 10c2df and then\n> select it's parent (i.e c76b6b) I get a big line ending in the commit\n> descriptions and four lines ending in midair.\n\nThat is an X server bug, it seems.  Tk already clips vertices that it\nsends to the X server to be within a box that is no more than 32000\npixels wide or high, but that seems not to be enough with some X\nservers.  What X server version are you using and what sort of video\ncard?\n\nIf you're feeling adventurous, you can rebuild Tk with the patch below\n(courtesy of D. Richard Hipp) and see if that fixes it.  If it does it\nproves that it is an X server bug.\n\nPaul.\n\n--- tkCanvUtil.c.orig   2006-02-08 08:51:31.859761208 -0500\n+++ tkCanvUtil.c        2006-02-08 08:57:11.744090936 -0500\n@@ -1657,25 +1657,27 @@\n \n     /*\n     ** Constrain all vertices of the path to be within a box that is no\n-    ** larger than 32000 pixels wide or height.  The top-left corner of\n+    ** larger than 16000 pixels wide or height.  The top-left corner of\n     ** this clipping box is 1000 pixels above and to the left of the top\n     ** left corner of the window on which the canvas is displayed.\n     **\n     ** This means that a canvas will not display properly on a canvas\n-    ** window that is larger than 31000 pixels wide or high.  That is no\n+    ** window that is larger than 14000 pixels wide or high.  That is no\n     ** a problem today, but might someday become a factor for ultra-high\n     ** resolutions displays.\n     **\n     ** The X11 protocol allows us (in theory) to expand the size of the\n     ** clipping box to 32767 pixels.  But we have found experimentally that\n-    ** XFree86 sometimes fails to draw lines correctly if they are longe\n-    ** than about 32500 pixels.  So we have left a little margin in the\n-    ** size to mask that bug.\n+    ** XFree86 has problems with sizes bigger than 32500 pixels and we\n+    ** have received reports of other X servers running in to trouble\n+    ** at around 29000 pixels.  So we are going to play it safe a limit\n+    ** pixel values to 14 bytes: 16384.  That is still sufficient for\n+    ** a 4x4 ft display at 300 dpi.\n     */\n     lft = canvPtr->xOrigin - 1000.0;\n     top = canvPtr->yOrigin - 1000.0;\n-    rgh = lft + 32000.0;\n-    btm = top + 32000.0;\n+    rgh = lft + 16383.0;\n+    btm = top + 16383.0;\n \n     /* Try the common case first - no clipping.  Loop over the input\n     ** coordinates and translate them into appropriate output coordinates.\n"},{"id":"19083","messageId":"20060425075429.GA1532@informatik.uni-freiburg.de","threadId":"3905","inReplyTo":"17485.31716.452326.229628@cargo.ozlabs.ibm.com","subject":"Re: [BUG] gitk draws a wrong line","fromName":"Uwe Zeisberger","fromEmail":"zeisberg@informatik.uni-freiburg.de","sentAt":"2006-04-25T07:54:29Z","receivedAt":"2006-04-25T07:54:29Z","isPatch":false,"sender":{"key":"u.kleine-koenig@pengutronix.de","avatar":"https://gravatar.com/avatar/354b5e3ceb2806a2f1e1e382ac29ddbdad18288654da62b61eb13583a857eee7?d=mp&s=160"},"body":"Hello Paul,\n\nPaul Mackerras wrote:\n> Uwe Zeisberger writes:\n> \n> > and then going to commit 10c2df65060e1ab57b2f75e0749de0ee9b8f4810, \n> > I see a small superfluous line between the two commits under 10c2df.\n> > \n> > But still worse, if I select the line going down from 10c2df and then\n> > select it's parent (i.e c76b6b) I get a big line ending in the commit\n> > descriptions and four lines ending in midair.\n> \n> That is an X server bug, it seems.  Tk already clips vertices that it\n> sends to the X server to be within a box that is no more than 32000\n> pixels wide or high, but that seems not to be enough with some X\n> servers.  What X server version are you using and what sort of video\n> card?\nIt's a Debian system with XFree 4.3.0.dfsg.1-14 and according to lspci I\nhave\n\n\t0000:01:00.0 VGA compatible controller: ATI Technologies Inc Radeon RV100 QY [Radeon 7000/VE]\n\n> If you're feeling adventurous, you can rebuild Tk with the patch below\n> (courtesy of D. Richard Hipp) and see if that fixes it.  If it does it\n> proves that it is an X server bug.\nOK, I tried that and it helped. \n\nI list my steps for people who want to \"fix\" it, too:\n\n\tNote: You need a deb-src line in your sources.list.  Moreover\n\tsome packages are assumed to be installed (e.g. devscripts,\n\tfakeroot, vim :-))\n\n\t~$ mkdir src; cd src\n\t~/src$ apt-get build-dep tk8.4\n\t~/src$ apt-get source tk8.4\n\t~/src$ cd tk8.4-8.4.12\n\t~/src/tk8.4-8.4.12$ vim generic/tkCanvUtil.c\n\n\t[ apply the patch provided by Paul/D. Richard Hipp ]\n\n\t~/src/tk8.4-8.4.12$ dch -n\n\n\t[ write a sensible changelog entry ]\n\n\t~/src/tk8.4-8.4.12$ fakeroot dpkg-buildpackage\n\t...\n\n\t~/src/tk8.4-8.4.12$ cd ..\n\t~/src$ sudo dpkg -i tk8.4_8.4.12-1.1_i386.deb\n\nI'm not entirely clear what this patch does.  From only reading it, I\nassume it should only have an effect on rather big windows, right?\n\nDo you know some more details about the bug?  Do you know to who it\nshould get reported?\n\nThanks for your help\nUwe\n\n-- \nUwe Zeisberger\n\nhttp://www.google.com/search?q=gravity+on+earth%3D\n"}]}