Asbjoern Pettersen wrote: > Here's a possible GIMP bug discovered in the 1.1.9 OS/2 version: > > -------------------- > Hi! > > I have a VERY bad bug here - it is 99% not OS/2 but please inform GIMP > programmers about it. > > 1. Open any picture > 2. Select clone tool "C" - select there to get source from image not from > pattern > 3. Ctrl-Click LMB anywhere! Be very accurate now! > 4. Move pointer 2-3 pixels from old point > 5. Press LMB and you'll see cursor # 2 is making ugly tracks on image!! > > 5 professional painters are using GIMP/2 now - this is one of their first > annoying bugs found. > ------------------------------- > > Asbjorn P. > *********************************************************** > * Asbjørn Pettersen Phone work: +47 77 66 08 91 * > * Kongsberg Spacetec a.s Phone home: +47 77674022 * > * Telefax: +47 77 65 58 59 * > * Prestvannveien 38 www:http://www.spacetec.no * > * N-9005 Tromsoe, Norway email:ape@xxxxxxxxxxx * > *********************************************************** Gentlepeople, I have been able to reproduce this bug using a different platform, IRIX 6.5.4 using SGI 4Dwm, GIMP checkout current to Friday, Sep .10 19:43 EDT 1999. It appears the clone tool samples its own sampling cursor; it appears to matter in what direction one goes after designating the "sample from" point; traveling 2 or three pixels along an "up," "down", "left" or "right" direction almost always ensures the capture of the "sample from" cursor image, ensuring a deposit of its "ghost" at the "sample-to" point. The trail of "ghost" sample cursors does not appear to be actually in the image. Creating any kind of host display exposure event promotes a refresh that does not restore the artifacts of the sample cursor, nor can the sample cursor subsequently resample the artifacts, nor do saved images contain any artifacts. The problem is almost (but not quite) outside the providence of the application. Though I haven't looked at the code, I speculate that "in principle" The Gimp is doing the right thing. Since one can't assume a display manager can provide more than one hardware cursor, the sampling cursor has to be "soft", i. e., written into the display. The affected display region has to be repaired when moving the cursor, and because it isn't a "real" window manager cursor, it is the Gimp's responsiblity to manage the housecleaning. It is quite likely that the logic is in place to "remove sample cursor, sample pixmap, paint offset pixmap, repaint sample cursor...", but latency in actually repainting the sample cursor upsets the ideal of the repainting logic, which assumes, perhaps, that repainting happens the instant it asks for it. Repainting actually happens in the bowels of some kind of window manager running on some sort of display server - a separate process, with all kinds of concurrency issues. At this site, the Gimp display happens to be xhosted to another machine, though the problem persists when the X display is local to the machine. That is my idle speculation, untroubled by the existence of mere facts. Perhaps today I can actually look at what's going on and confirm or demolish my theory. Garry R. Osgood
