On Wed, 11 Aug 2010 jcup...@gmail.com wrote: > > On 11 August 2010 02:14, Allin Cottrell <cottr...@wfu.edu> wrote: > > rid of GdkGC. I'd imagine that the effect I'm after is something > > that many GTP apps have need of, and it's trivial to achieve with > > the GDK API. > > I've found that XOR rubber banding is quite hard to do reliably in > gdk. The problem I think is that you are using the screen pixels to > store part of the state, and that gets hard to coordinate between the > various things that can affect the display. > > I had mouse movements triggering rect moves, mouse moves with a button > held down causing background scrolling of the canvas, and mouse moves > over other screen objects triggering highlight effects. With all these > things going on at once it became very difficult to get XOR rubber > bands to not leave annoying trails as they moved. > > I switched to an update-model / invalidate-widget / redraw-on-idle > scheme as Dov suggests and I got prettier updates with less > complication. Since input and output are decoupled, it'll scale more > gracefully between slower and faster machines as well, which is nice.
My drawing case may be simpler than yours -- there's nothing scrollable in the vicinity -- but I've found that rubber-banding using GDK_INVERT to "undraw" the last box works flawlessly at low programming cost. But can you suggest a good example to look at for the alternative approach? Thanks. Allin Cottrell _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
