Re: more on re- draw at end of re-size



"tony K." <tony kwok 3web net> writes:
Not really. GTK has nothing to do with window resizing; it's the window
manager's job. All GTK is getting is an X event telling it that the window
state has changed (ConfigureNotify?). There's no way GTK *can* get this
information.

Win32 can... It provides an end-of-resize message... It is an
important and identifiable action in the GUI repertoire. 

Sure, but X does not have this message, so GTK can't respond to it or
forward it to the application. What I'm saying is, don't blame GTK for
this, there is nothing GTK can do; it has no involvement in the resize
operation and receives no messages related to it other than "your
window has a new size."
 
Serious drawing applications hardly ever draw to a window; they draw
to a "shadow pixmap" from which the window is refreshed as
necessary. When a user starts resizing, a window is continously (and
quicky) refreshed from (now size mis-matched) shadow - it's the best
and the most reasonable the application can possibly do in a series
of quicly following re-size messages. (Much better and no more
time-consuming than "frame" resizing. Frame-resizing is for
Win3.0... :). When the user ends the interaction (releasing the
mouse button) the old pixmap is deleted, and a new one, of the right
size, is allocated, its content is repainted (possibly in a separate
task, so it does not interfere with the GUI response at all) and a
re-paint message is posted. The code that follows does just that,
but, since the button-up event is unobtainable, it does the best it
can by timing the resize messages. I post it here as an example of
the behaviour I was describing above, for those that might have any
use for it, and especially for those that can improve on it and
share the result with the audience...

I'm aware of the backing store technique, the "scribble" example in
the GTK tutorial uses this, and GTK 2 just does it automatically for
all drawing, so there's no point doing it explicitly in the app.

Resizing the pixmap on each resize event will be plenty fast for GTK,
don't worry about it. GTK 2 is constantly creating pixmaps for the
backing store, on resizes and in many other cases. There's no point
trying to put in hacks to avoid pixmap creation, if nothing else all
your work will be pointless for GTK 2 since GTK will create pixmaps
behind your back. ;-) But even with 1.2 it's pointless, because
there's no speed issue here.

Havoc





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