QGraphicsView + QGLWidget problem

[Thomas Senyk]

On Wednesday, June 13, 2012 05:56:01 AM ext Steve Pike wrote:
> Hi Thomas,
> 
> Thank you for your response.
> 
> I can see that incorporating QWidgets is QGraphicsView is a kind of backward
> compatibility mode and is not to be used for new projects. I am stuck with
> porting a very large piece of code to Android that happens to use QWidgets
> this way.There is animation, transparency, swiping effects and a lots of
> QTextEdits and all widgets are customised by deriving from original Qt
> classes.In short: I really wouldn't know where to begin if I wanted to do
> this using QtQuick, also given the time constraints.
> 
> 
> I had no idea it was wrong and unsupported as the standard Qt demos feature
> a few examples featuring widgets that are animated, transformed and
> transparent, including dialog boxes.

The problem is that for qt on android it's 100% opengl or 0% opengl (see 
later)
And rendering QWidget-derived classes with opengl is unsupported.

> 
> Back to my problem:
> 
> Yes, it works if I go back to software rendering on Android (very slow) and
> it works brilliantly with OpenGL, but under Linux only. It is such a shame
> I can't use the acceleration. How I envision this to work is to have
> software rendering of QWidget derived classes into the texture cache and
> OpenGL rendering of these textures in the QGraphicsView. So what would it
> take to do this?
> 
> What is the problem with OpenGL? Can't it just use one context and switch it
> to render each element, one at a time? It can render multiple applications
> too, but serially, I would imagine.

The problem is that someone needs to compose all the native surfaces.
So far nobody was found who was willing to implement it.

I was asked before, but I will not implement it as I'm very skeptical 
regarding QWidget-opengl painting for various reasons.


I know this is a problem for users who want to port there 
QWidget+OpenGL/GraphicsView application to android 
... but I think the majority of applications need a new user-interface for 
touch-based application anyway (at least I try to convince myself about that 
:D)


Greets
Thomas


> 
> Cheers,
> 
> Steve
> 
> 
> 
> ----- Original Message -----
> From: Thomas Senyk <thomas.senyk at nokia.com>
> To: necessitas-devel at kde.org; Steve Pike <pike_steve at rocketmail.com>
> Cc:
> Sent: Tuesday, 5 June 2012, 14:36
> Subject: Re: QGraphicsView + QGLWidget problem
> 
> Hi,
> 
> I'm not sure ... but I think you're doing something horrible wrong :)
> 
> You're using QWidget-derived classes (e.g. QLabel) inside a
> OpenGL-accelerated QGraphicsView ... right?
> 
> 
> If yes, 2 things about that a bad:
> 1. "using QWidget-derived classes inside QGraphicsView"  (unrelated to
> opengl) This is wrong, unsupported, evil and makes your application slow :)
> This was once mentioned in the qt doc ... but it's gone now. maybe this
> features has become better ... but anyway: this is not the way forward! :)
> 
> 
> 2. "using QtOpenGL to paint QWidget-derived" (via viewport of QGraphicsView)
> This is unsupported by Qt and especially on embedded targets, it's not very
> well tested and not really maintained.
> Even more especially on android. QWidget-opengl-painting isn't fully
> implemented (e.g. some widgets need native surfaces; but this feature is not
> implemented)
> 
> 
> 
> Now the question is: What are you trying to do? :)
> If you want a simple (static) qwidget based application: Why use
> QGraphicsView?
> If you want a fancy (animated) UI: Why use QWidget classes?
> 
> If you want both (easy use of QWidget and performance of opengl):
> I would go to QtQuick (writing simple UI elements is a matter of minutes)
> 
> 
> 
> If you're stuck with old (bad?) code and you can't change your setup
> (QGraphicsView + QWidget)
>     ... I guess opengl on android is out of the question at the moment
> (you can always go back to SW-rendering by NOT linking against libQtOpenGL)
> 
> 
> Greets
> Thomas
> 
> On Thursday, May 31, 2012 06:17:00 AM ext Steve Pike wrote:
> > Hi,
> > 
> > My name is Steve and am new to the mailinglist.
> > 
> > I've submitted a bug report to Sourceforge regarding QGraphicsView +
> > QGLWidget under Android. BogDan asked me to join this mailinglist and
> > discuss the bug.
> > 
> > For a client I am porting their Qt based software to Android, for use on
> > Samsung Galaxy smartphones. Currently the system uses a QGraphicsScene and
> > QGraphicsView that is accelerated using a QGLWidget as the viewport, which
> > works fine under Ubuntu. Software is written in 100% C++, no QML.
> > 
> > Porting this using Necessitas is a pretty smooth operation and everything
> > works perfectly, as long as I don't use a QGLWidget as the viewport. When
> > I
> > do use GL acceleration, it seems that embedded widgets created using
> > addWidget() are resized to full screen within the QGraphicsView, resulting
> > in one widget, for example a label, dominating the screen, the rest being
> > invisible.
> > 
> > Temporarily uncommenting the code for this widget will result in another
> > GUI element appearing full screen. Getting the dimensions from the widget
> > and printing them to debugging output reveals that they are indeed
> > resized to screen dimensions and I cannot override this using
> > setGeometry.
> > 
> > I'm an experienced C/C++ hacker, so I will not only present my problem,
> > but
> > will hopefully solve it as well.
> > 
> > Yesterday, I found the following clues in the qandroideglfswindow.cpp and
> > I
> > looks like it is linked to my problem.
> > 
> > 
> > https://qt.gitorious.org/~taipan/qt/android-lighthouse/blobs/stable/src/pl
> > ug ins/platforms/android/src/opengl/qandroideglfswindow.cpp
> > 
> > 
> > Specifically:
> > 
> > void QAndroidEglFSWindow::setGeometry(const QRect &)
> > {
> >
> >     // We only support full-screen windows
> >     QRect rect(m_screen->availableGeometry());
> >     QWindowSystemInterface::handleGeometryChange(this->widget(), rect);
> >
> >     // Since toplevels are fullscreen, propegate the screen size back to
> >the>
> > widget widget()->setGeometry(rect);
> >
> >     QPlatformWindow::setGeometry(rect);
> >
> > }
> > 
> > 
> > ...
> > 
> > Qt::WindowFlags QAndroidEglFSWindow::setWindowFlags(Qt::WindowFlags type)
> > {
> >
> >     flags = type;
> >
> >     if (!widget()->isFullScreen() && flags != Qt::Popup && flags !=
> >Qt::Tool>
> > && flags != Qt::ToolTip && flags != Qt::SplashScreen)
> >
> >          widget()->setWindowState(widget()->windowState() |
> >
> > Qt::WindowMaximized); return flags;
> > }
> > 
> > 
> > In alpha4 there are some more modifications to this function that have to
> > do>
> > with maximizing widgets:
> >     QtAndroid::setFullScreen(widget());
> >
> > I think the problem is this:
> > 
> > When a widget is created without a parent, for example using 'new
> > QLabel()', the OpenGL window code makes it a full-screen top level
> > window, even though it is not shown yet.
> > 
> > If later I use addWidget() to embed this widget into a QGraphicsScene,
> > which is the normal way to go, this widget stays full screen and seems to
> > keep its window status. I thought the solution would be to create widgets
> > with the QGraphicsView or a dummy widget as the parent, but this is not
> > possible as addWidget() will not allow you to embed widgets that already
> > have a parent. Workarounds have failed, such as creating my GUI elements
> > with window flags like Qt::Tool, to prevent them being made full screen,
> > or removing the Qt::Window status after creating the widget.
> > 
> > These restrictions are not in the raster code. I hope anyone has some
> > ideas
> > about this.
> > 
> > Steve
> > 
> > 
> > 
> > Steve Pike
> > 
> > _______________________________________________
> > Necessitas-devel mailing list
> > Necessitas-devel at kde.org
> > https://mail.kde.org/mailman/listinfo/necessitas-devel