3 ms·

You are comparing potatoes with tomatoes. Swift is developed by Apple for Apple ecosystem. Thus, the native calls are of course efficient. Qt is a framework t

You are comparing potatoes with tomatoes. Swift is developed by Apple for Apple ecosystem. Thus, the native calls are of course efficient. Qt is a framework that works as bridge between the native calls and your application, the same applies for .NET. If you develop on windows with WPF/MFC/Win32 calls, it will be obviously faster than Qt, because you're saving on that bridge calls. Why don't you use Qt on Mac then? The main advantage of using such a framework is that you have only one codebase/language that runs everywhere.

MaxBarraclough 8y ago
You've contradicted yourself. WPF is a .Net technology. Are you saying it pays a performance penalty, or not? > If you develop on windows with WPF/MFC/Win32 calls, it will be obviously faster than Qt, because you're saving on that bridge calls. Not so. Both frameworks make calls down into one of Windows' graphics subsystems. This is how all GUI toolkits work. If draw performance is important to you, Qt might well beat WPF, as it has a Direct3D 12 backend [0]. To my knowledge, WPF does not - as far as I can tell it uses Direct3D 9. Of course, none of this gives us any hard assurances that the performance of one beats the other, but in terms of the inefficiencies of using intermediate layers, it's far from clear than WPF wins. (I couldn't find any decent concrete numbers on this. I presume that's because GUI draw performance isn't a real problem these days.) I'm not convinced that Swift is any different (though it well might be a good deal less bloated). It seems unlikely that the syscalls end up all that different simply because of using a different language for your GUI work. > Why don't you use Qt on Mac then? Obviously I can't speak for nicodjimenez, but I presume it's because Qt doesn't deliver quite the native Mac feel that they're aiming for. My understanding is that Qt is also a little immature on mobile platforms, but I'm not sure that's relevant here. [0] https://doc.qt.io/qt-5.11/qtquick-visualcanvas-adaptations-d3d12.html https://doc.qt.io/qt-5.11/qtquick-visualcanvas-adaptations-d...
- pjmlp 8y ago
  WPF makes heavy use of DirectX, .NET JIT can remove marshaling code on P/Invoke and COM calls and there is also NGEN for AOT compilation. .NET Core 3.0 will apparently finally bring .NET Native to Windows desktop apps as well.
vetinari 8y ago
MFC is a layer above Win32. So is Qt, except with better design and maintained. WPF is somewhere else; as the sibling commenter told you, it is a .Net framework, so it has entire .Net VM underneath.
- pjmlp 8y ago
  Just like C and C++ have MSVCRTL.dll.
- badsectoracula 8y ago
  > MFC is a layer above Win32 Not exactly and this view of it is IMO why a lot of people dislike it: MFC is not a layer like Qt, you don't use it to avoid Win32, you use it to enhance Win32. When using MFC you need to know both MFC and Win32 and you use both of them at the same time. On the other hand when you use Qt you can ignore anything related to Win32 because the Qt API layers itself over whatever is below. Of course this has several implications, starting with that if you don't like Win32 then you wont like MFC either (and the reverse isn't necessarily true - you may dislike MFC while liking Win32).
jcelerier 8y ago
> If you develop on windows with WPF/MFC/Win32 calls, it will be obviously faster than Qt, because you're saving on that bridge calls. Qt (Quick) is on the same level than WPF actually. Both create a scene graph and render it. WPF does not use native windows primitives.

MaxBarraclough 8y ago

You've contradicted yourself. WPF is a .Net technology. Are you saying it pays a performance penalty, or not? > If you develop on windows with WPF/MFC/Win32 calls, it will be obviously faster than Qt, because you're saving on that bridge calls. Not so. Both frameworks make calls down into one of Windows' graphics subsystems. This is how all GUI toolkits work. If draw performance is important to you, Qt might well beat WPF, as it has a Direct3D 12 backend [0]. To my knowledge, WPF does not - as far as I can tell it uses Direct3D 9. Of course, none of this gives us any hard assurances that the performance of one beats the other, but in terms of the inefficiencies of using intermediate layers, it's far from clear than WPF wins. (I couldn't find any decent concrete numbers on this. I presume that's because GUI draw performance isn't a real problem these days.) I'm not convinced that Swift is any different (though it well might be a good deal less bloated). It seems unlikely that the syscalls end up all that different simply because of using a different language for your GUI work. > Why don't you use Qt on Mac then? Obviously I can't speak for nicodjimenez, but I presume it's because Qt doesn't deliver quite the native Mac feel that they're aiming for. My understanding is that Qt is also a little immature on mobile platforms, but I'm not sure that's relevant here. [0] https://doc.qt.io/qt-5.11/qtquick-visualcanvas-adaptations-d3d12.html https://doc.qt.io/qt-5.11/qtquick-visualcanvas-adaptations-d...

pjmlp 8y ago
WPF makes heavy use of DirectX, .NET JIT can remove marshaling code on P/Invoke and COM calls and there is also NGEN for AOT compilation. .NET Core 3.0 will apparently finally bring .NET Native to Windows desktop apps as well.

vetinari 8y ago

MFC is a layer above Win32. So is Qt, except with better design and maintained. WPF is somewhere else; as the sibling commenter told you, it is a .Net framework, so it has entire .Net VM underneath.

pjmlp 8y ago
Just like C and C++ have MSVCRTL.dll.
badsectoracula 8y ago
> MFC is a layer above Win32 Not exactly and this view of it is IMO why a lot of people dislike it: MFC is not a layer like Qt, you don't use it to avoid Win32, you use it to enhance Win32. When using MFC you need to know both MFC and Win32 and you use both of them at the same time. On the other hand when you use Qt you can ignore anything related to Win32 because the Qt API layers itself over whatever is below. Of course this has several implications, starting with that if you don't like Win32 then you wont like MFC either (and the reverse isn't necessarily true - you may dislike MFC while liking Win32).

jcelerier 8y ago

> If you develop on windows with WPF/MFC/Win32 calls, it will be obviously faster than Qt, because you're saving on that bridge calls. Qt (Quick) is on the same level than WPF actually. Both create a scene graph and render it. WPF does not use native windows primitives.