I'm using MLT framework to create a video player for my app in which users will be able to preform some small video editing for a specific task. I'm also using QT for this app. I have started with essentially the BuildOnMe example which can be found here
The problem is the player crashes on videos after a certain time (always different).
At one point I was printing the number of frames to see if it was on the same number (it isn't) and when it crashed it printed this: [mlt_pool] out of memory
Do I need to take care of memory management for mlt?
I'm using QT5.3
My code, in case it helps, can be found here (I didn't add the .h)
I found out the problem was from the Mlt::Frame created in the function on_frame_show
This frame needs to be deleted, in the example it is used on the mac openGL class. But on windows since it's never used it'll quickly build up on the memory.
I made little sound generator in C# 4.0 using DirectSound.
I would like to mute all other sounds. I want only my application to be able to emit sounds.
How to do it?
I know how to pInvoke so you can give me unmanaged code.
Properly designed programs either stop playing back sound when their main window becomes deactivated. Or use IDirectSound::SetCooperativeLevel() so they play nice with other programs that want to be heard.
You are asking how to make a improperly designed program behave nicely. With a bit of a hint that you don't contemplate being nice yourself. Teaching that uncooperative program a lesson is simple, run its uninstaller. Avoid being the victim of that same advice.
I have an application written in QT4, that uses an openGL window. It has been running happily for months. Windows XP, service Pack 3,
Recently I was diddling with my screensaver, and happened to select the 3D text choice. When I previewed it, the QT4 application seg-faulted immediately. When I ran in the debugger,it is crashing in ig4dev32.dll, which is an intel graphics accelerator driver for Open GL.
When I do a similar test on a machine with an NVIDIA card, I (not surprisingly) get no problems.
I'm not really sure whether I'm asking for help, or insight, or whatever--has anybody ever seen it? Google tells me others have seen it happen in gaming applications, but I see no references to developers having it happen to them. Obviously, I can not use that screensaver, but I suspect the problem is "bigger" than that. Ideas?
I would start by reporting this to Intel. No doubt, they will not resolve it by the end of the week, but eventually. In the mean time, I'd also report it to Qt software, so see if they can trouble shoot it as well.
In the mean time, you know the issue and how to resolve it (no OpenGL screensavers). So all you have to do is to inform your customers. The best would be if the application itself could inform the customers, but detecting if a screensaver uses OpenGL or not does not seem feasable.
Perhaps you could do some additional tests. For instance, what happens if your application is run in paralell with, say, Google Earth in OpenGL mode?
I'm considering writing a new Windows GUI app, where one of the requirements is that the app must be very responsive, quick to load, and have a light memory footprint.
I've used WTL for previous apps I've built with this type of requirement, but as I use .NET all the time in my day job WTL is getting more and more painful to go back to. I'm not interested in using .NET for this app, as I still find the performance of larger .NET UIs lacking, but I am interested in using a better C++ framework for the UI - like Qt.
What I want to be sure of before starting is that I'm not going to regret this on the performance front.
So: Is Qt fast?
I'll try and qualify the question by examples of what I'd like to come close to matching: My current WTL app is Programmer's Notepad. The current version I'm working on weighs in at about 4mb of code for a 32-bit, release compiled version with a single language translation. On a modern fast PC it takes 1-3 seconds to load, which is important as people fire it up often to avoid IDEs etc. The memory footprint is usually 12-20 mb on 64-bit Win7 once you've been editing for a while. You can run the app non-stop, leave it minimized, whatever and it always jumps to attention instantly when you switch to it.
For the sake of argument let's say I want to port my WTL app to Qt for potential future cross-platform support and/or the much easier UI framework. I want to come close to if not match this level of performance with Qt.
Just chiming in with my experience in case you still haven't solved it or anyone else is looking for more experience. I've recently developed a pretty heavy (regular QGraphicsView, OpenGL QGraphicsView, QtSQL database access, ...) application with Qt 4.7 AND I'm also a stickler for performance. That includes startup performance of course, I like my applications to show up nearly instantly, so I spend quite a bit of time on that.
Speed: Fantastic, I have no complaints. My heavy app that needs to instantiate at least 100 widgets on startup alone (granted, a lot of those are QLabels) starts up in a split second (I don't notice any delay between doubleclicking and the window appearing).
Memory: This is the bad part, Qt with many subsystems in my experience does use a noticeable amount of memory. Then again this does count for the many subsystems usage, QtXML, QtOpenGL, QtSQL, QtSVG, you name it, I use it. My current application at startup manages to use about 50 MB but it starts up lightning fast and responds swiftly as well
Ease of programming / API: Qt is an absolute joy to use, from its containers to its widget classes to its modules. All the while making memory management easy (QObject) system and mantaining super performance. I've always written pure win32 before this and I wil never go back. For example, with the QtConcurrent classes I was able to change a method invocation from myMethod(arguments) to QtConcurrent::run(this, MyClass::myMethod, arguments)and with one single line a non-GUI heavy processing method was threaded. With a QFuture and QFutureWatcher I could monitor when the thread had ended (either with signals or just method checking). What ease of use! Very elegant design all around.
So in retrospect: very good performance (including app startup), quite high memory usage if many submodules are used, fantastic API and possibilities, cross-platform
Going native API is the most performant choice by definition - anything other than that is a wrapper around native API.
What exactly do you expect to be the performance bottleneck? Any strict numbers? Honestly, vague ,,very responsive, quick to load, and have a light memory footprint'' sounds like a requirement gathering bug to me. Performance is often overspecified.
To the point:
Qt's signal-slot mechanism is really fast. It's statically typed and translates with MOC to quite simple slot method calls.
Qt offers nice multithreading support, so that you can have responsive GUI in one thread and whatever else in other threads without much hassle. That might work.
Programmer's Notepad is an text editor which uses Scintilla as the text editing core component and WTL as UI library.
JuffEd is a text editor which uses QScintilla as the text editing core component and Qt as UI library.
I have installed the latest versions of Programmer's Notepad and JuffEd and studied the memory footprint of both editors by using Process Explorer.
Empty file:
- juffed.exe Private Bytes: 4,532K Virtual Size: 56,288K
- pn.exe Private Bytes: 6,316K Virtual Size: 57,268K
"wtl\Include\atlctrls.h" (264K, ~10.000 lines, scrolled from beginning to end a few times):
- juffed.exe Private Bytes: 7,964K Virtual Size: 62,640K
- pn.exe Private Bytes: 7,480K Virtual Size: 63,180K
after a select all (Ctrl-A), cut (Ctrl-X) and paste (Ctrl-V)
- juffed.exe Private Bytes: 8,488K Virtual Size: 66,700K
- pn.exe Private Bytes: 8,580K Virtual Size: 63,712K
Note that while scrolling (Pg Down / Pg Up pressed) JuffEd seemed to eat more CPU than Programmer's Notepad.
Combined exe and dll sizes:
- juffed.exe QtXml4.dll QtGui4.dll QtCore4.dll qscintilla2.dll mingwm10.dll libjuff.dll 14Mb
- pn.exe SciLexer.dll msvcr80.dll msvcp80.dll msvcm80.dll libexpat.dll ctagsnavigator.dll pnse.dll 4.77 Mb
The above comparison is not fair because JuffEd was not compiled with Visual Studio 2005, which should generate smaller binaries.
We have been using Qt for multiple years now, developing a good size UI application with various elements in the UI, including a 3D window. Whenever we hit a major slowdown in app performance it is usually our fault (we do a lot of database access) and not the UIs.
They have done a lot of work over the last years to speed up drawing (this is where most of the time is spent). In general unless you really do implement a kind of editor usually there is not a lot of time spent executing code inside the UI. It mostly waits on input from the user.
Qt is a very nice framework, but there is a performance penalty. This has mostly to do with painting. Qt uses its own renderer for painting everything - text, rectangles, you name it... To the underlying window system every Qt application looks like a single window with a big bitmap inside. No nested windows, no nothing. This is good for flicker-free rendering and maximum control over the painting, but this comes at the price of completely forgoing any possibility for hardware acceleration. Hardware acceleration is still noticeable nowadays, e.g. when filling large rectangles in a single color, as is often the case in windowing systems.
That said, Qt is "fast enough" in almost all cases.
I mostly notice slowness when running on a Macbook whose CPU fan is very sensitive and will come to life after only a few seconds of moderate CPU activity. Using the mouse to scroll around in a Qt application loads the CPU a lot more than scrolling around in a native application. The same goes for resizing windows.
As I said, Qt is fast enough but if increased battery draining matters to you, or if you care about very smooth window resizing, then you don't have much choice besides going native.
Since you seem to consider a 3 second application startup "fast", it doesn't sound like you would care at all about Qt's performance, though. I would consider 3 second startup dog-slow, but opinions on that vary naturally.
The overall program performance will of course be up to you, but I don't think that you have to worry about the UI. Thanks to the graphics scene and OpenGL support you can do fast 2D/3D graphics too.
Last but not least, an example from my own experience:
Using Qt on Linux/Embedded XP machine with 128 MB of Ram. Windows uses MFC, Linux uses Qt. Custom user GUI with lots of painting, and a regular admin GUI with controls/widgets. From a user's point of view, Qt is as fast as MFC. Note: it was a full screen program that could not be minimized.
Edited after you have added more info:
you can expect a larger executable size (especially with Qt MinGW) and more memory usage. In your case, try playing with one of the IDEs (e.g. Qt Creator) or text editors written in Qt and see what you think.
I personally would choose Qt as I've never seen any performance hit for using it. That said, you can get a little closer to native with wxWidgets and still have a cross-platform app. You'll never be quite as fast as straight Win32 or MFC (and family) but you gain a multi-platform audience. So the question for you is, is this worth a small trade-off?
My experience is mostly with MFC, and more recently with C#. MFC is pretty close to the bare metal so unless you define a ton of data structure, it should be pretty quick.
For graphics painting, I always find it useful to render to a memory bitmap, and then blt that to the screen. It looks faster, and it may even be faster, because it's not worrying about clipping.
There usually is some kind of performance problem that creeps in, in spite of my trying to avoid it. I use a very simple way to find these problems: just wait until it's being subjectively slow, pause it, and examine the call stack. I do this a number of times - 10 is usually more than enough. It's a poor man's profiler but works well, no fuss, no bother. The problem is always something no one could have guessed, and usually easy to fix. This is why it works.
If there are dialogs of any complexity, I use my own technique, Dynamic Dialogs, because I'm spoiled. They are not for the faint-of-heart, but are very flexible and perform nicely.
I once made an app to determine the "primeness" of a number (whether it was prime or composite).
I first attempted a Qt GUI, and it took 5 hours to return the answer for 1,299,827 on a computer with 8GB of RAM and an AMD 1090T # 4GHz running no other foreground processes under Linux.
My second attempt used a QProcess of a console application that used the exact same code. On a laptop with 1.3GB of RAM and a 1.4GHz CPU, the response came with no perceivable delay.
I will not deny, though, that it is far easier than GTK+ or Win32, and it handles things quite nicely, but separate intensive processing ENTIRELY from the GUI if you use it.
I've been playing a big with the DC obtained with CreateDC(L"DISPLAY",NULL,NULL,NULL) and I've been wondering why does windows let you draw on the whole screen that easily, cause I think you could do some pretty evil stuff with that like putting a TIMER at 1ms and drawing a black rectangle on the whole screen every time the timer ticks.
The fact that you could do some pretty evil stuff doesn't mean windows shouldn't let you do it. Just think of all the other evil things you could do:
Run in an infinite loop and eat up all the cpu time.
Write random bits to a file until you fill up the whole hard disk.
Delete random files all over the place.
Allocate memory like crazy until the computer slows to a crawl.
Just because you CAN do those things doesn't mean windows should prevent you from writing to the hard drive or allocating memory or deleting files.
The purpose of Windows is to provide an environment in which programs can run. The more flexible they make that environment, the more interesting (and, unfortunately, devious) programs it makes possible for developers to create.
If they started putting in arbitrary restrictions on what you can do because you might abuse it... well, then it wouldn't be windows, it would be an iPhone :)
why does windows let you write to the hard drive so easily?
you could do some pretty evil stuff like overwrite every file on the hard drive.
The security of the desktop is given to the user running the desktop, you can't draw on it if you are not a privileged user.
Note that one doesn't usually CreateDC() on the desktop, but usually GetDC() for a particular window during the WM_PAINT message handler.
A program can also delete the file system, or destroy the registry (if suitably permissioned), the desktop is a user-permissioned resource like any other. If they run an application with their security credentials, they can do what they wish.
However in practice, one would create a window and paint within it.
Because it should be that easy.
It is that easy because to put rules and controls in place would mean that you would be cutting down the things you can do with the language and the windows framework. If this happened then there would be screams from the other side of the fence shouting at how you can't do this and that.
It is these abilities which make the language powerful, but with that power comes the danger. Just because you can do something, doesn't mean that you should. You can format you hard drive... doesn't mean that you should do this when you launch the clock application.
If you are not happy with this level of 'responsibility' then pick a different language or framework to write in.
Everything is a Window and Every Window has a HANDLE. So, if you have got DesktopHandle, then you can draw anything on it. What is the problem with it.
Offcourse, the application that is doing evil stuff(like you said) has been allowed to run on the machine by yourself, therefore, it can do more eviler stuff than this such as formatting your hard-drive etc.
If the method you're using (getting the screen DC) was disabled, it wouldn't stop people from doing the following.
You can create a window, you can paint in the window, you can set the size of the window to cover the whole screen, therefore you can paint on the whole screen.
And you can grab a bitmap of the whole screen, so you can paint the underlying screen content in the window and then make adjustments to it.
So it would be very easy to simulate the same effect using a combination of things that, on their own, are perfectly valid and extremely useful.
Because there may be a time when you need to do these things. I am sure at the moment you can't think of any but writing on the screen may be useful.
On OS X there are many applications who write directly on the screen. Useful information like CPU time or even a calender. That's cool!
But not everything that can be done must be done.
One of the primary reasons Windows is so afflicted with malware is the lack of security around such things as you describe. Others have cited examples such as filling the hard drive, erasing random files, or eating CPU time... all of these things are security concerns, and all of them are prevented by the other two major operating systems (Linux and OSX). This doesn't mean that you can't do similar things on those operating systems, but it means that a normal user can't do it. They'd have to be granted the right permissions, and usually also forced to use a very restrictive API to limit what they can do. So the answer to your question is "because it wasn't designed with security in mind". This allows programmers significantly more flexibility, and these powers can be used for good, but IMHO it more often breeds laziness (people use the brute force way instead of spending the time figuring out the "right" way to do something) and opens the door for security problems (malware).