RE: draw signals



    Alan> I see...  but if all that has happened is that a pixmap became
    Alan> exposed, why have a handler redraw the pixmap if nothing has changed
    Alan> and a simple screen update will do?  It seems somewhat inefficient
    Alan> to do so, especially if multiple pixmaps are involved.  If I can
    Alan> find a way to only update the screen with an existing pixmap then I
    Alan> can save time and memory :-) I guess that's the problem I'm trying
    Alan> to solve: how do I prevent a pixmap from being redrawn when a simple
    Alan> screen update will do?  Is it possible to do this when, say, a
    Alan> window/widget gets uncovered?  The "draw" signal seems to only
    Alan> complicate things during an "expose_event".  Any help with this
    Alan> would be greatly appreciated.

Yes, it is inefficient, but it does remove one extra screen update.  Perhaps
an improvement could be made if you think about it another way: "When the
expose events come in, I make the assumption that the pixmaps are all
up-to-date and ready to be copied to the screen."

Then you consider what needs to be changed to make sure all the pixmaps are
current before an expose takes place.  In many cases, nothing actually needs
to be done, but I don't know your application, so that may not be a safe
assumption.
-----------------------------------------------------------------------------
Mark Leisher
Computing Research Lab            Cinema, radio, television, magazines are a
New Mexico State University       school of inattention: people look without
Box 30001, Dept. 3CRL             seeing, listen without hearing.
Las Cruces, NM  88003                            -- Robert Bresson




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