There is no need to copy something that is already invalid and will
be marked as invalid in the destination anyway, so we remove this
area from the region to copy.
The expose translation is useful for tracking how outstanding
invalid (exposed on server) areas are copied, and how we need to
compensate for that on the client side to redraw the right area.
So, we should queue the translation at the time we actually move
the bits on the server side, not when moving the window on the
client side.
Also, clean up some naming of parameters.
We now copy outstanding window moves directly on the window and
not to an intermediary pixmap, this means our previous code to
combine window copies was wrong (it relied on each copy not
destroying the source date).
Furthermore, we can't just remove all the update area from the
destination of the outstanding moves, as sometimes things get
copied into that area and then used as the source of another
copy.
We replace the previous window copy combining with a naive
version that just queues each move, just to get things right.
Further work to optimize copies is possible.
Also, we don't remove copy destinations that are used as source
for later copies.
We also clean up the memory management by not having
move_region_on_impl taking ownership of the passed in region.
Apps that set no exposure mask rely on the system clearing things
to the window background, so we need to do this ourselves.
Also, don't do this on foreign windows, as they are not controlled
by us. In fact don't do exposes on foreign windows either.
This is required for the GtkSocket code, as it shows the plug child
even though the current cached state is (wrongly) that its already
mapped.
This makes blink work for non-local case in testsocket.
Native descendants of a virtual children are not automatically destroyed
with the parent as if it was a native window, so we need to handle
the native recursion tracking manually in _gdk_window_destroy_hierarchy()
Some apps really need to set custom event masks on native child windows,
for example emacs sets the event masks with gdk, but then reads out
the raw X events via a filter, so gdk event emulation doesn't work for that.
When we get motion or button events we map back from the event position and
window to the toplevel before doing anything, because a toplevel native window
could e.g. overlap a child window or whatever.
These are generated when we get an implicit grab on a native
child window, and we can't filter them with _has_grab() because
they are sent before the button press event where we detect
the implicit grab.
This makes clicks work in the flash plugin again
It turns out we really have to ignore grab/ungrab events or we'll
report double crossing events when we grab or ungrab.
However, we also can't ignore crossing events from grabs from other clients
as that leads to missed enter/leave events on e.g. alt-tab in metacity.
Fortunately we now track grabs very precisely, so we know with certainty
whether we have a grab at the time (serial) of the native crossing events,
and only if we do we ignore them.
If we get crossing events with subwindow unexpectedly being NULL
that means there is a native subwindow that gdk doesn't know about.
We track these and forward them, with the correct virtual window
events inbetween.
This is important to get right, as metacity uses gdk for the frame
windows, but gdk doesn't know about the client windows reparented
into the frame.
Having GDK_WINDOW_CHILD windows with root as the parent apparently works,
and metacity uses it. The current gdk_window_get_toplevel() returns the
root window for that, which is wrong, so we check that explicitly.
This causes all sorts of weirdness with pointer_over_window
being the rootwindow and then crashing gdk_window_get_toplevel() later.
With this metacity stops crashing madly.
These are sent when someone else grabs the pointer, and we don't
want to miss these expose events. For instance, we missed enter
and leave events on alt-tab.
There were some issues with these wrt out-of-sync grab information
in the client, but that should now be handled. So, it should work
or at least be fixable if we find some bug.
Replace them with two new functions
_gdk_windowing_{before,after}_process_all_updates() that are called
around the guts of gdk_window_process_all_updates(). Add empty ones
for X11 (nothing more needed), quartz ones will be implemented next.
We use this in the added windowing function
_gdk_windowing_window_process_updates_recurse. The X11 implementation
just calls _gdk_window_process_updates_recurse directly, but at least
quartz will need to do some more work.
This fixes a problem where we used to set them on a native window, but we
never unset it becase when the pointer moved to another native window
we just set the cursor on that window. Always setting on the toplevel
fixes this.
There was a performance problem with the old flicker fixing
approach. For moved windows we copied the window data to the double
buffer pixmap and then back to the window with the rest of the
expose data. In some cases the copy from window data to pixmap was
very slow because the pixmap was allocated in system memory and
the window in video memory.
The new approach is to delay all window moves and then replay them
after the expose has drawn to the double buffer pixmap but before
drawing it to the window. Furthermore, we remove all exposed areas
from the destination of the delayed moves so we won't copy something
just to then immediately draw over it.
This makes scrolling in firefox fast, and it makes tests/flicker not
show any (detectable) flicker.
We return the raw window drawable, so its likely the app will do some
weird stuff to it, like draw using non-gdk operations. We don't want
the app to see any half-drawn state, so flush everything.
This fixes a scroll issue in firefox at least.
This is basically the same fix as was done for
gdk_window_move_resize_internal. We make sure not to move the native
child window contents twice and we don't copy data that was overwritten
by the moving of the native child windows.
