Re: gtk_widget_draw()
- From: Benjamin Otte <otte gnome org>
- To: Federico Mena Quintero <federico ximian com>
- Cc: gtk-devel-list <gtk-devel-list gnome org>, Havoc Pennington <hp pobox com>
- Subject: Re: gtk_widget_draw()
- Date: Thu, 12 Aug 2010 20:35:04 +0200
On Thu, Aug 12, 2010 at 7:27 PM, Federico Mena Quintero
<federico ximian com> wrote:
> - If you have an "event" signal in GdkWindow, like you proposed, then we
> can make widgets responsible for connecting to their subwindows. In
> theory the (client-side) window system will send those signals in Z
> order. We may need a hint to say "send me an expose for this parent
> window even if a child window obscures it" for if you want to have
> transparent windows - you want the parent to paint its background, and
> then the child to overlay its stuff.
>
> - We can have gtk_widget_register_subwindow(w, window), called by widget
> implementations. Then the stock GtkWidget code magically connects to
> "expose" on those GdkWindows, and calls ::draw() as appropriate. I
> guess this is roughly similar to moving gdk_window_set_user_data() into
> GTK rather than GDK. Then the "draw" method would be called with a clip
> region set to the appropriate subwindow, or something.
>
If you have transparent windows, you want two things:
1) Drawing the parent window does not draw to the child window
2) Updating the child window does not require drawing parent windows first.
(1) would be overkill, because we might end up drawing everything twice.
(2) is important because you might want to use the translucent window
as a source for some drawing operations elsewhere and if that'd
automatically draw the stuff below it first, you couldn't do that.
What complicates the matters here is that in some cases it's the
windowing system that composites and in some cases it's GDK that does.
And to make matters more interesting, there's different windowing
systems with different ideas on how stuff should work.
There is also the possibility of declaring all native windows opaque
and have client-side windows not send expose events at all. This would
have 2 advantages:
1) It'd work fine when we'd just called the draw function of child
widgets, though it'd change how we handle it right now.
2) We wouldn't need to do all those mad clipping hacks we currently do.
The proper decision also depends on wether we want to support using
any window as a source for drawing operations. Currently GDK does not
allow doing that.
Again, just random thoughts,
Benjamin
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]