Re: porting gdk -> cairo

I don't know if you noticed it in another thread, but I created a working
example of the approach that I described in my earlier email. See:

See the program test-dovtk-lasso.c for an example of  how to use it.

Please let me know if you need more explanations. The source code isn't very
well documented yet.

On Wed, Aug 11, 2010 at 20:12, Allin Cottrell <cottrell wfu edu> wrote:

On Wed, 11 Aug 2010 jcupitt gmail com wrote:

On 11 August 2010 02:14, Allin Cottrell <cottrell 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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]