I have a Qwidget inside of which, I have multiple children in the form of QmlApplicationViewer objects, each pointing to a different qml file.
Problem is, when I use mouse, all the qml files take events, but when I try to use the touch screen, only some of them does.
Can someone give a direction as to where the problem might be ? Will appreciate and sort of possible causes which might cause this issue.
Platform : Ubuntu 12.04 - Qt 4.8 - 32 bit
There really is not enough information here to even begin to answer this question. The most obvious answer that comes to mind is some of your qml files are not correctly defining the TouchArea within the qml. If you want more help you need to post code.
I tried using the EG-Touch touch drivers for my platform, which are supposed to have some issues on 12.04(as per some forums). I reverted back to Ubuntu 11.04 and used the e-Galax touch drivers instead, and things are working fine now.
P.S. : If someone finds a working driver for 12.04 or any other work around, please update. I will accept a better answer. Closing this for now.
Related
I'm trying to make an 'fps' camera in OpenGL using Qt. I'm able to move the mouse and rotate the camera accordingly, the only problem I'm having is that I have to click and drag in order for it to happen (the mouseMoveEvent is only called when the mouse is being pressed). Now I've been searching around all day, and there is a lot of conflicting and outdated information about OpenGL on the internet. My question is really quite simple, does the QOpenGLWidget have some functionality similar to glutPassiveMotionFunc, or do I have to install the glut library to get this functionality? Other suggestions to get this functionality (other, better documented libraries for example) are also welcome. In case I have to install the glut library, it would also be amazing if someone would have documented a proper way of doing this, because I seem to find a million different ways, all equally hard to understand.
By default, Qt doesn't handle simple mouse move events. It has to be turned on via the mouseTracking property:
yourOpenGLWidget->setMouseTracking(true);
I'm using three different QGLWidgets in the same main thread, preferably rendered at 60fps but I cannot achieve more than 20fps. It seems that this is caused by Vsync as each widget probably tries to synchronize with the refresh rate independently and therefore they lock somehow. If I only use two widgets I achieve 30fps. Or if I fix the update rate of one widget to, let's say 10fps, I reach 25fps on the others (10+25+25=60). swapInterval() always returns 0, independent of the value I set with setSwapInterval(int). Any ideas? Can I disable Vsync? Or might the problem be caused by something different?
It seems that its currently the bug from Qt 5.0 - https://bugreports.qt.io/browse/QTBUG-29073
Turning the Vsync off will solve the problem with dividing update rate between QGLWidgets, your graphics card will render to screen as fast as you tell it to or as fast as it can. But you must disable the VSync in graphics card settings. Just setting fmt.setSwapInterval(0) will do nothing.
Unfortunately another problem raises, if you are painting video that contains horizontal moves, tearing will appear.
Hopefully the Qt 5.3 shall fix this bug.
For those who are still struggling with this issue, my short answer is: before trying anything else: install Qt 5.4.
Longer answer:
I never had any issue to disable VSync with Qt 4.8.
Using Qt 5.3.1 (in Kubuntu 14.04 64bit), I have never been able to force my QGLWidget not to sync at VBlank, which means that swapBuffers() was blocking no matter what. I disabled VSync both in the "Desktop effect" panel and the NVidia control panel, and setSwapInterval(0) to no avail. Therefore my fps have always been clamped to 60fps/numOfQGLWidget (unless I used SingleBuffering, but the flickering was not tolerable in my applications). Using multi-threading, it should theoretically be possible to have VSync enabled (hence no tearing), and achieve 60fps for multiple QGLWidget, but I failed to have that working as well.
Today, I just installed Qt 5.4, and it magically solved the issue: I can successfully have a non-blocking swapBuffers(), as I used to in Qt 4.8. I think Qt 5.3 forced VSync somehow no matter what you driver settings were. But it is no longer the case in Qt 5.4, at least in my configuration. It seemed the Qt team did a lot of work to improve OpenGL for Qt 5.4 (notably, they introduced the QOpenGLWidget class), so my advice to anyone using OpenGL with Qt would be to make the update to Qt 5.4, it will likely make your life easier.
For some reason, my QTableView seems to never emit a single signal. At first I tried connecting to any slot programmatically, but then I realized even through the Signal/Slot Editor from the GUI I could not make something happen, no matter which signal or slot I chose.
One detail that I noticed after a lot of research was that the Qt Documentation specifies that "The signal is only emitted when the index is valid.", so I understand this may be a problem with my models.
However, I still have no idea what might be the issue, or how I can fix it. Displaying the cells work perfectly fine on all models I have, but none of them seem to provide the correct signaling behavior, so I can't really detect the problematic code to post it.
It might be relevant to note, I tried disabling editing, and I'm testing this on Mac OS X Lion 10.7.5.
I appreciate any help. This is my first question here, although I've long benefited from those asked by others. So, yes, I've thoroughly searched for solutions.
Okay, I finally figured it out. After I realized Qt Creator was never updating the executable, no matter which code I changed, it was simply a matter of manually cleaning the build directory. Using the GUI options to do so (either rebuild or clean+build) hadn't had any effect. I guess it's because I had renamed the project, but didn't update the build directory or something. I had changed (improved) so much code since then that I would never have guessed there was an issue as everything was working fine, until I decided to add some more functionality.
As I had expected, this is kind of underwhelming for my first published issue, but I don't think it deserves negative points. The reason I didn't post some self-contained code is because I had no idea which code was causing the issue; I suppose I was just expecting someone with more experience to point me in the right direction. In the end, it wasn't even an issue with my code, it was with Qt Creator, so I really couldn't have been clearer.
I'll keep this as it might be useful for other people, so
tl;dr Qt Creator was silently failing to recompile the code, and the solution was to manually remove the old binaries.
Recently I started seeing the following nonsense with the satellite images in my Google Earth plugin:
The incorrect tiles fade in and out as I zoom, and at some zoom levels everything looks fine.
This happens across browsers (chrome, IE9, Firefox), but only on my machine. I've tried re-installing the plugin, but that didn't seem to help.
I'm using plugin version 6.2.2.6613
Does anyone know what might be causing this problem?
I have seen this problem before and again recently. The first time I was told it could be conflicts with the hardware accelerators but then the problem just went away.
Until recently I have had two instances of the plugin running in the same desktop application with no problems. Then a couple of days ago I started seeing the problem again although it is not happening today. I don't know if it would help but I would suggest rebooting your computer.
I've also wondered if Google was updating the plugin or the maps...
Sorry I can't be of any help but I suspect it will go away soon.
It looks like a DirectX issue to me. One possibility to fix is to force the plugin to use OpenGL instead.
You can control whether the plugin usese DirectX or OpenGL by altering the registry key:
HKLM\SOFTWARE\Google\GoogleEarthPlugin\Render\RenderingApi
The allowed values are:
0 (DirectX)
1 (OpenGL)
Try setting the value to use OpenGL to see if it resolves the issue.
Also, if it is a DirectX issue you could try disabling direct3D (as well as and texture acceleration) via the dxdiag as others have suggested.
Finally, you could also try disabling write combing on your card if it is enabled. This is usually done via the display properties for the card you are using.
I found that problem only occurs when I have multiple instances of the plug-in running. Especially if I have it running in two different browsers at the same time.
I work on a QML-based UI where some elements are implemented in C++ plugin.
Everything worked fine so far in WinXP 32bit and Win7 32bit. Last week I got new laptop with Win7 64bit on board, and my code does not work properly there. Several seconds after start-up application behaves nicely, but then suddenly view stops redrawing. Neither QML-initiated events, nor plug-in calls to QDeclarativeItem::update() work. In plugin I am 100% sure that update() is called, but then I know, that calls to overriden QGraphicsItem::paint() do not happen as expected. The view only gets redrawn when window gets/looses focus.
I have quickly verified my application on a desktop running Win7 and had no problems there. This leads my to suspect that there is something different about how Windows 7 requests window update on my laptop and on other computers, however I am unable to figure out the difference right now.
Can someone help me out to understand what is going on there?
Thanks in advance!
p.s. Unfortunately my primitive mock-ups did not exhibit same problem, and I cannot share production code. If I will find a way to reproduce this problem in a prototype before actual solution will be found, I will post it.
Add a qapp->processEvents() after your update() call, it will probably work.
(I've come across a similar problem, but it happens on all platforms, hopefully this solution will work for you)
The answer to my question lays in something I overlooked initially in my problem description. The QDeclarativeItem::update() function was called from a non-Qt thread (certainly not GUI thread). I re-routed the call through Qt event loop and the problem was gone.
I was on Qt 4.7/4.8 at that time and cannot say how it'd behave in Qt 5.x.