Re: Canvas redraw priority / speed



On 23 Aug 2002, Federico Mena Quintero wrote:

> You should be fine with something like (GDK_PRIORITY_EVENTS + 5), that
> is, a lower priority than events but higher priority than the canvas
> update/redraw cycle.  It should work if I understand your scheme
> correctly.

I tried that (with canvas from HEAD), but it gave much worse results than
updating from G_PRIORITY_LOW. Actually, I think anything higher than the
canvas update cycle will be slow -- as this will produce lots of canvas
item creations/deletions totally in vain.

Mind you, canvas HEAD with G_PRIORITY_LOW is still a lot slower than the
GNOME 1 version was. But maybe GTK+ itself is at fault here as well, since
some GTK+ widgets (like spinbuttons) are updated 'live' as well.


-- 
   .--= ULLA! =---------------------.   `We are not here to give users what
   \     http://cactus.rulez.org     \   they want'  -- RMS, at GUADEC 2001
    `---= cactus cactus rulez org =---'
If this had been a real emergency, we would have all fled in terror, and you would not have been notified.

_______________________________________________
gnome-hackers mailing list
gnome-hackers gnome org
http://mail.gnome.org/mailman/listinfo/gnome-hackers



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