Sometimes (not always), certain text items in the Qt Creator UI are broken:
Any idea what causes it? Or a workaround?
Maybe the problem is my cheap video card (an Intel on-board one). This theory is supported by the fact that Creator is probably QML-powered by now, meaning it's running on OpenGL.
I tried restarting Creator and that fixed it, but after switching between the Welcome and Edit tabs a few times, it happens again.
I tried making Creator's UI use the software QML renderer, rather than OpenGL, as that might have made it work correctly. I did it by running the following in cmd.exe:
> set QMLSCENE_DEVICE=softwarecontext
> qtcreator.exe
But that didn't fix it.
It turns out the solution is the same as that to the problem I posted next, i.e. to make the app (Qt Creator in this case) use ANGLE. Except I don't want to recompile Qt Creator just to add one line of code, so I use the alternative approach in the Qt doc page, which is to set the env var QT_OPENGL to angle, before launching Creator.
At least so far it hasn't bugged out on me.
Note: The setting of an env var can be done conveniently with a batch file as described here.
Related
I am currently testing the GTK Application that I built on windows using the MSYS2 64bit shell.
For the program to be able to run outside of the shell, I packed all the required DLLs with it as well as the following:
FOLDER\lib\gdk-pixbuf-2.0\2.10.0\loaders\\*
FOLDER\lib\gdk-pixbuf-2.0\2.10.0\loaders.cache
FOLDER\share\glib-2.0\schemas\gschemas.compiled
FOLDER\share\icons\Adwaita\\*
FOLDER\share\icons\hicolor\\*
The good news is: It works :) And it also works flawlessly on another PC that doesnt have GTK/Msys2/whatever installed.
The bad news is: On yet another PC (I have tested it on 2 other Systems other than my developing System so far, one one of them it works flawlessly), the program itself works, but the GUI is not rendered sharply (texts are blurry).
Do you guys have any idea on what could be the reason for that? I'm guessing it could be one of the following:
The affected system could have some general display problems that have nothing to do with my app.
The gschemas.compiled file does not suit the affected system. In that case I would probably have to create that file dynamically, but I have no idea how to do this.
I am missing some file from GTK or Glib that would solve the problem.
I am thankful for any help :) Compiling/Deploying a GTK App for Windows has proven to be a pain in the ***, but since (almost) everything works now, I feel like its not much that I am missing unless I have overseen something critical.
Regards,
tagelicht
Given the way you created your package, my bet is that you are missing some components, making the drawing code use some fallback routines, hence the "sharp" drawing.
Try to run the application in command line on the machine where your have the problem, to see if there are some unusual warnings you don't have when running it on your machine.
See also my answer on how to distribute a GTK+ application on Windows.
I'm using node-webkit to build a self-contained web app demo, and for some reason, the -webkit-backface-visibility CSS3 property doesn't work – but only when I run the app on Windows, not on Mac.
When I say it doesn't work, I mean it's exactly as if the property isn't supported: when I flip an element over on its back, I see it reversed, rather than hidden.
The issue isn't only with my particular code, either, as online demos of -webkit-backface-visibility (like this one) don't work when I run them in the app on Windows:
Is this a bug in node-webkit? Is there any way I can get this to work?
Well, it sounds like a bug. It might be the same issue that causes WebGL not to be available with specific hardware/driver combinations on Windows:
https://github.com/rogerwang/node-webkit/wiki/Webgl-support-on-windows
On Windows with some hardware and driver, WebGL won't work until you copy D3DCompiler_43.dll and d3dx9_43.dll to node-webkit's directory, or install DirectX 9 redistributable.
For license reasons we cannot ship those DLLs.
This seems to have fixed a similar problem with backface-visibility reported here:
CSS: backface-visibility and perspective doesn't work
It WORKS! Thanks a lot! I've added two dll files two node-webkit package and it works!
Background: I am currently in the process of creating a simple VNC viewer embedded in a QWidget for use on Windows. For this, I compiled the Qt-only VNC version of KRDC (remote desktop viewer for KDE) as well as its dependency libvncclient on windows. The problem which arose now however lies in the way krdc sends key events over vnc: it simply sends the value of QKeyEvent::nativeVirtualKey(), which on X11 is conveniently already a valid RFB keysym. On Windows however, this is not the case.
Now, to solve this problem, I think the best (and ultimately also portable) way is to translate Qt's QKeyEvent::key() and ::modifier() data back to valid X11/RFB keysyms. This seems somewhat complex though given that I need to pick different keysyms depending on modifier state (XK_a vs XK_A, I've only considered shift so far) as well. Looking into how X11 -> Qt translation is done in Qt's source code didn't really help either.
Might there already be a library or code snippet out there which accomplishes this? Or should I just attempt to write my own (incomplete) translation routine? If so, what would be the best way to go about this and also, are there other caveats related to X11 I should be aware of?
Well, seems like I'm actually blind; there was a reference in krdc's code, right below the e->nativeVirtualKey() statement, referencing another project's class where they encountered the exact same problem as me:
// hmm, either Win32-platform or too old Qt so we have to handle and
// translate Qt-key-codes to X-keycodes
I didn't test their solution but it seems solid. As I only discovered this now, I have already written a small routine myself which should work ok for most latin keyboards (but will probably break if the Qt team changes any of the Qt::Key values), if anyone is interested in it: link
I'm developing a very simple application for the Mac OSX platform making use of Qt and OpenGL (and QtOpenGL) so crossplatform gets easier.
The application receive a variable number of video streams that have to be rendered to the screen. Each frame of these video streams is used as a texture for mapping a rectangle in 3D space (very similar to a videowall).
Apart from the things such as receiving, locking, uploading video data, synchronizing threads... i consider it is clear that it's a quite simple application.
The fact is that all behaves ok when using cocoa based Qt 4.7 binaries (the default ones) in a 10.5 Mac.
But my code has to run fine at all of the OSX versions starting from (and including to) 10.4. So i tried the code in a 10.4 machine and it crashed just when starting. After a few hours of internet reading, i discovered that for a Qt Application to be targeted at 10.4, carbon Qt based has to be used. So i rebuild the whole project with the new framework.
When the new resulting binary gets run, all works well except by the fact that application's fps fall to about 2 fps!! And it behaves the same at both machines (10.5 computer has sensibly better features)
I've spent quite time working on this but i have not reached a solution. Any suggest?
More information about the application and things i've tried
code has not been modified when recompiling carbon based
only two (256x256 textures) videos ar used in order to assure it's not a bandwidth limit problem (although i know it shouldn't because the first code worked)
the 2 video streams arrive from network (local)
when a video stream arrives, a signal is emmited and the data will be uploaded to an OpenGL texture (glTexSubImage2D)
a timer makes render (paintGL) happen at about 20ms (~50 fps)
the render code use the textures (updated or not) to draw the rectangles.
rendering only when a video arrives won't work because of having 2 (asynchronous) video streams; besides more things have to be draw at screen.
only basic OpenGL commands are used (no PBO,FBO,VBO,...) The only one problematic thing could be the use of shaders (available only from Qt 4.7), but its code is trivial.
i've made use of OpenGLProfiler and Instruments. Nothing special/strange was observed.
Some things i suspect (conclusions)
it's clear it's not a hardware issue. The same computer behave differently
it gives me the sensation it's a threading/locking problem but, why?
carbon is 32 bits. The 10.5 application was 64. It's not possibly develop 64 bits in carbon.
for giving away the 32 bits possible cause, i also rebuild the first project for 32 bits. It worked partically the same.
i've read something about carbon having problems (more than usual) with context switching.
maybe OpenGL implementation is Multithread and code is not? (or the opposite?) That could cause a lot of stalls.
maybe carbon handle events differently from cocoa's? (i mean signal/event dispatching, main loop...)
Ok, this is (sorry for the so long writing) my actual headache. Any suggestion, idea.. would be very appreciated.
Thx in advance.
May I ask a diagnostic question? Can you ensure that it's not being passed to the software renderer?
I remember that when 10.4 was released, there was some confusion about quartz extreme, quartz and carbon, with some of it disabled, and hardware renderers disabled by default on some of them, which required configuration by the end user to get it working correctly. I'm not sure whether this information is pertinent, because you say that, having targetted 10.4, the problem exhibits on both the 10.4 and the 10.5, yes?
It's possible (though admittedly I'm grasping at straws here) that even in 10.5 carbon doesn't use the hardware renderers by default. I'd like to think though that OSX prefers hardware renderers to software renderers in all scenarios, but it may be worth spending a little time looking into, given how thoroughly you're already looking into other options.
Good luck.
If you are using Qt, I guess your code would work on a windows or linux platform. Have you tried your application under these platforms ?
This would quickly reveal if it comes from Qt or the mac OSX version.
I'm having a problem getting OpenMP and OpenCV to play nicely with a new project in Xcode. The project in its current state does nothing but grab frames from the default camera and put them into a window. This functionality works. However, I would like to grab the frames in a separate thread, and I was hoping I could get some experience with OpenMP.
Merely checking the checkbox to enable OpenMP in Xcode wreaks havoc. The program, while it will compile, load and run just fine, will not respond to any events -- period. It just sits there, drawing grabbed frames. (I do get the OS X beachball, too, even though it's running fine.) I eventually have to force quit the app or kill it from Xcode. Keep in mind I get this behavior even without any OpenMP #pragmas -- I have only to enable the option in Xcode.
Any ideas on how to solve this?
I'm just guessing here. You might need to make sure that all OpenGL drawing commands are called from one thread.