5 ms·

>Essentially all AV vendors. Not sure that's an especially good thing to be proud of :> Joking aside, I'm not sure I see your point with that clock. Windows w

by pikzen 10y ago

>Essentially all AV vendors. Not sure that's an especially good thing to be proud of :> Joking aside, I'm not sure I see your point with that clock. Windows with transparent elements? We've been able to do that for quite a while now. If you're referring to drawing that clock, I can use GDI on Windows and have the same result. With a bit of creativity you could probably have the hands rotate automatically with a binding, but my WPF is much too rusty for that.

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.
      - 10y ago
c-smile 10y ago
>>Essentially all AV vendors. > Not sure that's an especially good thing to be proud of :> Applications of that kind has quite strict requirements for performance, memory footprint, distribution size, incremental development of product that lives more than 10 years, etc. Like this product: http://sciter.com/from-skeuomorph-to-flat-ui-evolution-of-one-application/ http://sciter.com/from-skeuomorph-to-flat-ui-evolution-of-on... survived transition from skeuomorphism to Metro style UI on the same code base. CSS rulez!

by pikzen 10y ago

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.
    - 10y ago

c-smile 10y ago

>>Essentially all AV vendors. > Not sure that's an especially good thing to be proud of :> Applications of that kind has quite strict requirements for performance, memory footprint, distribution size, incremental development of product that lives more than 10 years, etc. Like this product: http://sciter.com/from-skeuomorph-to-flat-ui-evolution-of-one-application/ http://sciter.com/from-skeuomorph-to-flat-ui-evolution-of-on... survived transition from skeuomorphism to Metro style UI on the same code base. CSS rulez!