QGraphicsView + QGLWidget problem

Steve Pike pike_steve at rocketmail.com
Wed Jun 13 04:56:01 UTC 2012


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.

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.

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/plug
> 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



More information about the Necessitas-devel mailing list