You should be able to just fill the delta regions between the cursor position changes right? Basically a backwards "L" shape if you're dragging upper-left to lower-right. You would need to do two rect copies (or two calls to gtk_widget_queue_draw_area for each part of the L) as opposed to one. If items have a visible selected state that changes as you drag, then the regions for those items should simply be invalidated (but only if their state changes) along with the rubber band regions using gtk_widget_queue_draw_area.
On Thu, Apr 12, 2012 at 1:20 PM, Roger Davis <r...@soest.hawaii.edu> wrote: > > > Hi John and Simon, > > OK, experiment complete. Performance for me is very clearly not as good as > Xlib-style XOR when drawing rubberband lines which span a screen-sized > window (which is more or less typical for my apps, unfortunately), but on > the other hand it's not unusable either, just somewhat annoyingly jerky. > With smaller drawing areas (e.g., 300x300) the rubberbanding is perfectly > smooth. Playing around with motion hint events might clean this up a little > more. I'm basically doing a cairo_rectangle()/cairo_fill() from my entire > off-screen surface to the GtkDrawingArea after every MotionNotify event. > There are special cases, e.g., small rectangular rubberband boxes, where > this is horrific overkill, but I also have cases where I need to rubberband > larger collections of unpredictably-oriented line segments which span the > full window, so I think my worst-case scenario experimental implementation > has been a reasonable test. The outcome could have been worse, and I was > expecting that it would be! For now I'll tell my users to wait 5 years and > then buy new hardware. ;-> > > Thanks for all your suggestions! > > Roger > _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
