Re: Cullng drawing depending on visibility events



On Fri, 2003-04-04 at 06:54, Soeren Sandmann wrote:
> Federico Mena Quintero <federico ximian com> writes:
> 
> > So I wrote a quick patch to make the drawing functions not do anything
> > if windows are fully obscured.
> > 
> > Is this overkill?  I haven't really noticed any speed-ups with it even
> > with gnome-terminal/VTE spewing stuff in the background.
> 
> Usually the expensive part of gtk+ drawing is walking the widget tree
> emitting expose signals, not executing the drawing primitives, so just
> making the drawing primitives no-ops is probably not going to make a
> big difference.

Not only that, but if you only do it at the actual drawing stage, then
you have the overhead of creating the backing store pixmaps and
filling them in.

Looking at Federico's patch, my guess is that the drawing part
of it is basically doing nothing since GTK+ never draws onto windows
directly, but rather draws onto backing store pixmaps and copies them.
The only thing that will get optimized out is the final copy to the
destination
pixmap.

> So my guess is that gnome-terminal is still spending a lot of time
> drawing stuff, even though all the "drawing" is done with no-op
> primitives.

This doesn't sound so plausible to me ... most of the VTE drawing
time _is_ actually drawing the characters from what I've seen.

I think it's simply that the drawing is still being done to
the backing pixmap.

(gdk_window_scroll() optimization for fully_obscured might help
a bit for VTE though.)

> > It may also be desirable to modify gdk_window_invalidate_region() to do
> > nothing if the window is fully obscured --- I'm thinking of applications
> > that force repaints that way.
> 
> This is a good idea, I think. If you can make sure that a window is
> never invalidated when it is fully obscured, then the expose signal
> will never be emitted and no drawing (real or no-op) will take place.
> 
> I modified your patch to do this instead, and a quick test with
> pixbuf-demo showed that it works. It should also work for
> vte, but I don't use gnome-terminal anymore, so I haven't tested it.

Doing things on the invalidate path definitely seems correct to me.
If people are directly drawing to windows themselves, they can
take responsibility for handling visibility themselves.

At first glance, though, the change to
gdk_window_impl_x11_get_visible_region() in Federico's patch
should take care of this... you could save a little bit
of region manipulation, but I wouldn't expect it to make
a noticeable difference.

So, I think the first step would be to investigate what goes
on with Federico's patch without the drawing portions. 

As for the FIXME:

+         /* FIXME: we should only do this if the visibility event did
not come
+          * with associated exposures.  Would XIfEvent() be what we
need here?
+          */
+         if (window_impl->fully_obscured)
+           gdk_window_invalidate_rect (window, NULL, FALSE);
+

This can be omitted:
 
 - If GDK_EXPOSURE_MASK is in the window's event mask, then 
   it isn't necessary
 - If GDK_EXPOSURE_MASK isn't in the window's event mask, then
   invalidate_rect() will end up doing nothing. (See
   gdk_window_process_updates_internal())

Regards,
                                             Owen





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