Geometry changes may come from Qt itself, or spontaneously from the windowing
system. In both cases we deal with them through the layoutSubviews callback,
which we now ensure gets called after we set a new geometry on the UIView
frame, by using the setNeedsLayout message.
We take care to persist the requested geometry from Qt immediately in our
setGeometry() function, so that subsequent calls to QWindow::geometry()
will report back the requested geometry. Clients can however not rely
on this geometry until they've received a corresponding resize event,
which we trigger from layoutSubviews.
Since the new geometry reported in layoutSubviews may be different from
what the user requested, we ensure to pass on both the new and the "old"
geometry, so that Qt will send the appropriate resize and move events.
Instead of building expose events on top of the existing layout
mechanism provided by iOS, we hook into the more logical point,
which is the display-phase. Since a EAGL view normally doesn't
need to "display" anything this takes a few overrides on UIView.
Once we have the hooks we need, we can distinguish between a QWindow
backing needing layout, and needing displaying.
Finally, we flush both the resize and expose events, as that's what
iOS expects of us when asking us to layout or display. The result
is that Qt is able to synchronously resize subwindows and prepare
new GL rendering for the next frame.
Change-Id: I4c03e3db3fe886163284ba1a342699e217e88cbb
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
1ca27d38bc