I think this problem needs to be solved for putting scrollbars and
docked panels and all kinds of other graphics around the OpenGL
viewport. Special-casing window borders is not the solution.
It is true that the solution I have seen on both X and Windows is to
make a child window and draw the OpenGL into that. This produces all
kinds of nasty graphics artifacts when windows are resized or internal
layout changes. I think there will be a need for "subwindows" in Wayland
(though they are not inside, just stacked, with the shell keeping them
together). These are going to be needed so the subwindow can have a
different color space or transform, but it seems wasteful to use this
for restricting OpenGL.
The other solution that is closer to what I recommend is to use scissor
and the projection matrix to restrict drawing to a given subrectangle,
and the client code is just not supposed to do OpenGL calls that will
break that. On X (and I think on Windows) this has the unfortunate
side-effect that you have to use OpenGL for *all* drawing in the window.
It would be nice if wayland (or egl?) fixed this. Another way is to use
an OpenGL backend for Cairo to draw these parts.
As far as I can tell all large 3D applications (like Maya) either go the
all-OpenGL route, or they use Qt and subwindows.
In any case I am very wary of any solution that treats the window
borders as special. The solution must also solve putting scrollbars
around the openGL or it is not a correct solution. It would be really
nice if the solution did not require creating otherwise useless extra
surfaces.
On 11/04/2012 12:10 PM, Giulio Camuffo wrote:
The problem is not the Qt API but OpenGL. There's no other way of
translating the contents than telling somehow the offset to the client
and let the developer accout for it, which is not acceptable.
Actually, thanks to
http://doc-snapshot.qt-project.org/5.0/qopenglcontext.html#defaultFramebufferObject
a
FBO solution is doable. But doable only, not good and not optimal at all.
Giulio
2012/11/4 Bill Spitzak <[email protected] <mailto:[email protected]>>
The Qt drawing api should be set with a translation, and possibly
with a clip, so that when the contents are drawn into the buffer
they are offset correctly to miss the area the window border is
drawn into.
On 11/03/2012 04:46 AM, Giulio Camuffo wrote:
Hi all,
I'm trying to get decorations in QtWayland for EGL apps. The problem
that I'm facing is that I cannot find a good way to do so.
One solution could be to use an FBO, let the client draw in that and
then draw the content of the FBO into the surface whith its nifty
decoration. This would work but what happens if the client in its
rendering code calls glBindFramebuffer(0)? It will start drawing
directly to the surface and it will screw up badly.
Using an EGL pixel buffer would solve the issue, as I can call
eglMakeCurrent with that, but copying its content to the surface
is slow.
A faster thing would probably be wl_egl_pixmap but it's gone.
The ideal solution would be to have an EGL extension that lets call
eglMakeCurrent with a rect that defines the boundaries of the
drawable
surface.
There's NV_post_sub_buffer
(http://www.khronos.org/__registry/egl/extensions/NV/__EGL_NV_post_sub_buffer.txt
<http://www.khronos.org/registry/egl/extensions/NV/EGL_NV_post_sub_buffer.txt>)
but wl_egl_windows don't seem to support it.
So I'm stuck. Does anyone have an idea?
Giulio
_________________________________________________
wayland-devel mailing list
wayland-devel@lists.__freedesktop.org
<mailto:[email protected]>
http://lists.freedesktop.org/__mailman/listinfo/wayland-devel
<http://lists.freedesktop.org/mailman/listinfo/wayland-devel>
_________________________________________________
wayland-devel mailing list
wayland-devel@lists.__freedesktop.org
<mailto:[email protected]>
http://lists.freedesktop.org/__mailman/listinfo/wayland-devel
<http://lists.freedesktop.org/mailman/listinfo/wayland-devel>
_______________________________________________
wayland-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
_______________________________________________
wayland-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
