Re: [gtk-list] Re: styles and writeable colormaps
- From: Havoc Pennington <hp redhat com>
- To: gtk-list redhat com
- Subject: Re: [gtk-list] Re: styles and writeable colormaps
- Date: Tue, 16 Nov 1999 13:51:45 -0500 (EST)
On Tue, 16 Nov 1999, Dean Skuldt wrote:
>
> Yes, using motion notify hints seems to cause a motion notification event
> to occur only at the start of motion and at the end of motion. For my
> application, I really want to have continual re-rendering while motion is
> occuring, so I have ruled out using motion notify hints.
>
Have a look at the "scribble" example in the tutorial, or the chapter in
my book; the motion events come only when you ask for the pointer
location. This means they come "as fast as you handle them." If you aren't
calling gdk_window_get_pointer() you will only get one or two events.
> I'm not sure how using an idle function would help to optimize the
> application. I haven't used one, but it seems as though by doing this the
> draw would occur only when nothing else is happening. Would this mean
> that motion notifications could be continually sent, but somehow draw
> commands would not be stacked up?
>
What I mean here is a one-shot idle function. The canvas uses this
approach. The idea is that whenever an update is needed, you install an
idle function if and only if it isn't already installed; you "queue a
redraw." All redraw-queuings after the first one have no effect. When the
event loop becomes idle, your idle function actually runs. In the idle
function, remove the idle function. Then next time an update is needed
re-add the idle.
Basically the idea is to compress all the events in a "burst" into a
single update operation, waiting for things to quiet down before you
actually do any updating.
Havoc
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]