8 ms·

"I can use GDI on Windows and have the same result." Sorry but you should refresh your GDI knowledge (if it makes sense these days at all). You simply cannot r

by c-smile 10y ago

"I can use GDI on Windows and have the same result." Sorry but you should refresh your GDI knowledge (if it makes sense these days at all). You simply cannot render that with GDI. GDI does not know anything about a) antialiasing nor b) it knows anything about alpha-channel. The only function that is available to you is ::AlphaBlend that is not even in GDI API but from msimg32.dll. And that function takes a bitmap. So you need some primitives to rasterize things like canvas.lineTo(point1, point2) with AA. And for GDI to do that on CPU side. And CPU based rendering with modern 4K displays (Retina grade displays) makes no sense - on 192 DPI screen you need to produce 4 (four) times more pixels than on used to be standard 96 DPI displays. Our processors haven't grown that far in last 5-10 years. So forget about GDI, its time is over. So if to think not just in yesterday's terms then the only option are GPU based renderers based on DirectX, Vulcan, Metal and OpenGL as a last resort. Starting any projects today that relies on CPU based rasterization - pure waste of time - no present and no future.

DaiPlusPlus 10y ago
It's sad. I wish Microsoft had improved and advanced GDI instead of starting anew with WPF (now Jupiter) such that we had a 2D UI toolkit suitable for the modern world instead of multiple competing, but only partially overlapping, frameworks (e.g. WPF is useless if you're doing native C++ and, but GDI lacks intuitive modern graphics features). What strikes me is how Microsoft removed 2D hardware acceleration from GDI+ in Vista (wrecking performance, hence the shitty XOR operation framerate) and then introduced Direct2D without providing a clear upgrade path for developers. What also sucks is that GDI and Win32 are so heavily intertwined it means that other frameworks (like WPF, Direct2D, etc) cannot integrate as well.
- c-smile 10y ago
  GDI is an immediate mode graphics API that conceptually cannot be used with GPU style batch rendering. When each drawing operation is just a command record to be sent to GPU for later execution. Yet things like GDI::SetROP2 make no sense in GPU context when rasterization is made in parallel. GDI uses integer coordinates - not that scaleable. GDI::COLOR type limits R,G,B by 0..255 values only... Too many problems. But I shall admit that Direc2D API, that is C++ thing, could be made in more GDI-ish, plain C, style.
- Const-me 10y ago
  > I wish Microsoft had improved and advanced GDI instead of starting anew with WPF The improved and advanced technology you’re describing is called GDI+. There’re things like anti-aliasing and alpha-blending implemented there. They work fine, but for compatibility reasons, it still renders on CPU. Those years (mid-‘00s) there was a trend towards high-resolution displays, at that time it meant FullHD, driven by HD-DVD/BluRay. And a trend from desktops to laptops. It was already obvious GPU rendering was inevitable. The CPU and GPU are just fundamentally different. Hence the new GPU-centric technology. > GDI and Win32 are so heavily intertwined True, those two are coupled very tight. There’s a good reason for that: performance. Win32 API largely based on Win16. And Windows 1.0 was running on systems like Intel 8088 4.77MHz, 640kB RAM. There wasn’t enough resources for better abstractions.
- pjmlp 10y ago
  > WPF is useless if you're doing native C++ Not for those of us on Windows 8 onwards. The way forward for C++ UIs is XAML, which is just the underlying foundation of WPF.
  - int_19h 10y ago
    There is a pretty big difference between WPF, and the XAML UI Framework that you get in UWPs. When it comes to desktop apps, at least, WPF had a lot more features, and was generally more flexible and extensible. XAML UI is much closer to Silverlight, if anything.
    - DaiPlusPlus 10y ago
      When a new UI framework comes out, my test is: "Can Adobe build the next version of Photoshop with this?". WinForms and WPF failed the test because they can only be run from within .NET applications. I was hopefull for Direct2D, but D2D is only a drawing API, there are no native widgets. XAML with C++ is nice in Windows 10, but I understand your application must run in the sandbox (for better and for worse) and when you use Win10 XAML you cannot use any UI code that uses any of the old-world code (e.g. Photoshop plugins). I'm also concerned that XAML prevents you from getting lower-level control over hardware (e.g. Deep-color support, hosting low-latency OpenGL contexts, etc). The sandbox requirement itself kills it for a lot of applications anyway. Today, if you're writing a C/C++ program for Windows that needs to display a native Windows checkbox on screen (i.e. the Common Controls library or the raw Checkbox window class), and you want to customise how that checkbox is rendered, then you're still stuck with GDI - the WM_Paint message gives you access to s GDI device context in RAM - so you have to jump through hoops to use it with another 2D library or widget toolkit. How do I get an opaque handle to the window's texture surface in VRAM for ultra-fast painting or low-level control?
      - pjmlp 10y ago
        The future is sandboxed Windows, there is no way around it. So while XAML with C++ does indeed require WinRT and sanboxing. That is where future Windows versions will be. For high performance graphics there is DirectX and it interoperates perfectly fine with XAML. There are quite a few examples, including VS templates. As for Win32, the Anniversary edition will bring the productified version of project Centennial, which allows running Win32 applications as sandboxed WinRT apps. This is intended as a porting aid to bring Win32 apps into the new world, not as as something to use for new applications.
- int_19h 10y ago
  GDI is not a UI toolkit, though. It's a rendering API. Direct2D is the replacement for that. I'm not sure what you mean by "multiple competing partially overlapping frameworks", because e.g. WPF is not it. And, aside from WPF, which is really just lagging behind at this point, the rest of the Windows ecosystem is on D2D right now (e.g. UWP).

by c-smile 10y ago

DaiPlusPlus 10y ago

It's sad. I wish Microsoft had improved and advanced GDI instead of starting anew with WPF (now Jupiter) such that we had a 2D UI toolkit suitable for the modern world instead of multiple competing, but only partially overlapping, frameworks (e.g. WPF is useless if you're doing native C++ and, but GDI lacks intuitive modern graphics features). What strikes me is how Microsoft removed 2D hardware acceleration from GDI+ in Vista (wrecking performance, hence the shitty XOR operation framerate) and then introduced Direct2D without providing a clear upgrade path for developers. What also sucks is that GDI and Win32 are so heavily intertwined it means that other frameworks (like WPF, Direct2D, etc) cannot integrate as well.

c-smile 10y ago
GDI is an immediate mode graphics API that conceptually cannot be used with GPU style batch rendering. When each drawing operation is just a command record to be sent to GPU for later execution. Yet things like GDI::SetROP2 make no sense in GPU context when rasterization is made in parallel. GDI uses integer coordinates - not that scaleable. GDI::COLOR type limits R,G,B by 0..255 values only... Too many problems. But I shall admit that Direc2D API, that is C++ thing, could be made in more GDI-ish, plain C, style.
Const-me 10y ago
> I wish Microsoft had improved and advanced GDI instead of starting anew with WPF The improved and advanced technology you’re describing is called GDI+. There’re things like anti-aliasing and alpha-blending implemented there. They work fine, but for compatibility reasons, it still renders on CPU. Those years (mid-‘00s) there was a trend towards high-resolution displays, at that time it meant FullHD, driven by HD-DVD/BluRay. And a trend from desktops to laptops. It was already obvious GPU rendering was inevitable. The CPU and GPU are just fundamentally different. Hence the new GPU-centric technology. > GDI and Win32 are so heavily intertwined True, those two are coupled very tight. There’s a good reason for that: performance. Win32 API largely based on Win16. And Windows 1.0 was running on systems like Intel 8088 4.77MHz, 640kB RAM. There wasn’t enough resources for better abstractions.
pjmlp 10y ago
> WPF is useless if you're doing native C++ Not for those of us on Windows 8 onwards. The way forward for C++ UIs is XAML, which is just the underlying foundation of WPF.
- int_19h 10y ago
  There is a pretty big difference between WPF, and the XAML UI Framework that you get in UWPs. When it comes to desktop apps, at least, WPF had a lot more features, and was generally more flexible and extensible. XAML UI is much closer to Silverlight, if anything.
  - DaiPlusPlus 10y ago
    When a new UI framework comes out, my test is: "Can Adobe build the next version of Photoshop with this?". WinForms and WPF failed the test because they can only be run from within .NET applications. I was hopefull for Direct2D, but D2D is only a drawing API, there are no native widgets. XAML with C++ is nice in Windows 10, but I understand your application must run in the sandbox (for better and for worse) and when you use Win10 XAML you cannot use any UI code that uses any of the old-world code (e.g. Photoshop plugins). I'm also concerned that XAML prevents you from getting lower-level control over hardware (e.g. Deep-color support, hosting low-latency OpenGL contexts, etc). The sandbox requirement itself kills it for a lot of applications anyway. Today, if you're writing a C/C++ program for Windows that needs to display a native Windows checkbox on screen (i.e. the Common Controls library or the raw Checkbox window class), and you want to customise how that checkbox is rendered, then you're still stuck with GDI - the WM_Paint message gives you access to s GDI device context in RAM - so you have to jump through hoops to use it with another 2D library or widget toolkit. How do I get an opaque handle to the window's texture surface in VRAM for ultra-fast painting or low-level control?
    - pjmlp 10y ago
      The future is sandboxed Windows, there is no way around it. So while XAML with C++ does indeed require WinRT and sanboxing. That is where future Windows versions will be. For high performance graphics there is DirectX and it interoperates perfectly fine with XAML. There are quite a few examples, including VS templates. As for Win32, the Anniversary edition will bring the productified version of project Centennial, which allows running Win32 applications as sandboxed WinRT apps. This is intended as a porting aid to bring Win32 apps into the new world, not as as something to use for new applications.
int_19h 10y ago
GDI is not a UI toolkit, though. It's a rendering API. Direct2D is the replacement for that. I'm not sure what you mean by "multiple competing partially overlapping frameworks", because e.g. WPF is not it. And, aside from WPF, which is really just lagging behind at this point, the rest of the Windows ecosystem is on D2D right now (e.g. UWP).