On Sat, 2004-07-10 at 17:29, Soeren Sandmann wrote: > At > > http://bugzilla.gnome.org/show_bug.cgi?id=113310 > > Owen said: > > I think that we shouldn't unset the background for windows without the > EXPOSURE mask - if you unset the EXPOSURE mask, to me, that says that > you want what the X server is going to draw. To provide a bit more background about my comment, we've already occasionally seen issues with the unsetting of the background when scrolling/resizing. http://mail.gnome.org/archives/gtk-devel-list/2004-April/msg00049.html is one. Though that particular problem might be fixed by your patch which does an empty begin-paint/end-paint to force a background update. I'm a bit worried that when we start unsetting the background as well on map, we'll find out that some people have been creating windows with the background set to avoid having to run the event loop. > so the patch I committed contains a check for the EXPOSURE mask. If it > isn't there, the window won't get its background unset. This is a > problem, because some widgets create "invisible" windows, typeically > for clipping purposes, that [...] > I see two possibilities > > 1) Go back to unsetting the background for such windows and draw > the background manually for windows without EXPOSURE > > 2) Fix the widgets (I noticed it for GtkViewport and GtkTextView - there > may be others). Well, a possibility 3) would be to unset the background only on resize on not on map. I don't think there is a theoretical basis for it, but it might work well in practice. (The advantage of unsetting on map for expose-less windows is that then you can map windows in any order without getting flashes, but I don't think anybody is relying on that currently.) My suggestion for a resolution here is to go with 1) but keep 3) in mind if bug reports start coming in. Regards, Owen
Attachment:
signature.asc
Description: This is a digitally signed message part