New V11 Charting Features for .NET (WinUI, WPF, Winforms), MFC, VCL, ActiveXI. Improvements Overview:Version 11 is primarily a platform, interface, and user-experience release. Where past major versions focused on new chart properties and rendering engines (including v10's GPU-side ComputeShaders expansion), v11 broadens where ProEssentials runs and modernizes how end users interact with a chart at run time. The main headline additions are: - New WinUI 3 interface;
- New native ARM64 support across the .NET 10, .NET 8, and .NET 48 interfaces (.NET 48 AnyCPU covers x64, x86, and ARM64 from one build);
- New .NET 10 interfaces across WinUI, WPF, and Winforms;
- New modern built-in .NET-centric menu and dialog UX (with improved WYSIWYG image export and print dialogs) across all the .NET interfaces, plus built-in localization in 19 languages with no satellite assemblies;
- New improved TestBed - export any individual demo example as its own standalone, ready-to-build starter project, so you begin from working code instead of a blank page;
- Under the hood, modernized native-engine loading and improved .NET interfaces that create less friction moving from eval to retail DLLs.
What ties these additions together is what stays the same underneath. Every ProEssentials interface - from the original Win32 DLL through the ActiveX controls, Windows Forms, WPF, and now WinUI - is a thin interface over one mature, native charting engine that Gigasoft has refined for decades. v11 is largely the work of bringing that same engine to new places: a native ARM64 build of the engine, a WinUI interface that hosts it through Direct3D and Direct2D composition, new .NET 10 targets, and a single .NET Framework AnyCPU build that runs native on x64, x86, and ARM64 alike. Because the engine itself is proven and unchanged, this added reach costs nothing in stability or rendering performance - and your existing Pexxx code carries across interfaces with little more than a control type-name change. If upgrading, most existing code continues unchanged. As always your feedback is greatly appreciated. If you have a specific use-case needing attention, let us know. If you need a current feature fixed or tweaked, let us know. If you need a new feature, let us know. II. New WinUI 3 Interface:Delivering a native charting interface for each generation of the Windows UI has been Gigasoft's focus for 30 years, from the original Win32 DLL and the VBX for Visual Basic 1, to the ActiveX (OCX) controls, to .NET Windows Forms, then WPF, and now the modern WinUI 3. Version 11 adds Gigasoft.ProEssentialsWinUI, a first-class .NET interface joining Winforms and WPF. Microsoft advertises WinUI as the new modern "native" interface moving forward. And ProEssentials' WinUI interface is truly the most "native" "native" interface backed by native Direct3D plus Direct2D C++ based binaries. Across every .NET interface, the ProEssentials charting and rendering engine is native, pre-compiled C++ built on Direct3D and Direct2D; the .NET layer is only a thin managed wrapper over it. The CLR therefore never JIT-compiles a huge managed charting engine - only the lightweight wrapper is JIT'd, at negligible cost - and at load time ProEssentials binds the architecture-correct native engine (x64, x86, or ARM64) for full native rendering performance on each. This architecture has delivered native-speed charting for over twenty years, while much of the industry rewrote their engines in fully managed C# and absorbed the JIT and throughput cost that comes with it. For 30 years, Gigasoft has always been dedicated to native-built charting, and greatly appreciates Microsoft re-committing itself to the future of native. WinUI is also the long-overdue modernization of WPF, whose visual layer has remained tied to the now-ancient DirectX 9. The WinUI control instead renders through modern Direct3D and Direct2D composition swap chains hosted directly in the XAML visual tree, and exposes the same Pexxx property, method, and event API you already use in the other interfaces, so porting example code between interfaces remains straightforward. The WinUI control targets .NET 10 (WindowsAppSDK) and ships as a single control DLL with every supported language embedded (no satellite assemblies). It supports the same chart types and the new built-in UX described below. One thing to know up front: WinUI deployment is heavier than WPF or WinForms. Because WinUI depends on the Windows App SDK, a deployed app needs two runtimes on the target machine - the .NET 10 Desktop Runtime and the Windows App SDK Runtime - or you publish it self-contained so both runtimes travel inside the app folder and nothing needs to be installed. Also remember that a .NET app is a launcher exe plus its DLL and JSON config files, so you deploy the whole output folder, not a single exe. One related tip worth knowing early: in your own WinUI project, reference the Microsoft.WindowsAppSDK.WinUI and Microsoft.WindowsAppSDK.Runtime component packages rather than the all-in-one Microsoft.WindowsAppSDK umbrella package. The umbrella transitively pulls the Windows AI / ML / ONNX runtime into your output - roughly 40 MB across a dozen extra DLLs, including DirectML.dll and onnxruntime.dll - that your application likely never uses. Engine additions it took to render on WinUI: Hosting a native engine inside a XAML visual tree is not a matter of pointing the existing renderer at a new window. A WinUI control has no HWND of its own to draw into, so v11 adds a windowless presentation path to the engine. It creates its own DXGI flip-model composition swap chain (BGRA8, two buffers, FLIP_DISCARD) and hands that swap chain to the XAML host through ISwapChainPanelNative::SetSwapChain. From that point DWM composites the chart's pixels directly into your visual tree, with no intermediate WriteableBitmap and no per-frame CPU copy. A Direct2D device context created on the same D3D11 device targets the back buffer itself, so 2-D chart content is drawn by the GPU straight into the buffer that is about to be presented. Rendering is done in device pixels at 96 DPI with a half-pixel transform, which is what keeps axis rules and grid lines landing on exact pixel boundaries rather than smearing across two. Presentation was tuned rather than left at defaults. DXGI will happily queue two or three frames ahead, so the engine calls SetMaximumFrameLatency(1) to keep the present queue from growing. Combined with the long-standing ProEssentials habit of rendering on demand - presenting when your data changes rather than on a continuous 60 fps loop - the chart stays responsive under interaction without spinning the GPU while nothing moves. The new RenderPriority property lets a zoom-box drag outrank routine chart repaints so the box tracks the pointer instead of starving behind them. The 3-D path needed work of its own. DXGI does not permit a flip-model composition swap chain to be multisampled, so when MSAA is enabled the engine renders the 3-D scene into an offscreen multisampled target and resolves it down into the single-sample back buffer, keeping smooth surface-plot edges without giving up composition-based presentation. The 2-D and 3-D swap chains also differ in alpha mode deliberately. The 2-D chain is premultiplied so a chart can composite over the XAML background beneath it, while the 3-D chain is opaque, because the 3-D scene clears with zero alpha and the Direct2D axis overlay writes color but not alpha; under a premultiplied chain DWM would treat those overlay pixels as transparent and the titles, legend and axes would silently disappear. Overlay content received the same treatment rather than a compromise. Real-time table annotations render into a second, fully transparent composition swap chain, created on the same D3D11 and Direct2D devices and bound to its own panel in the control template. It shares the chart's half-pixel transform so the two layers align pixel for pixel, and it repaints independently - updating a live table overlay does not re-render the chart underneath it. Worth stating plainly for anyone upgrading: all of this was added alongside the existing render paths, not in place of them. The WinUI work is gated so the Winforms and WPF interfaces continue through the same code they used in v10, which is why a release this large costs nothing in stability for the interfaces you already ship. III. Native ARM64 Support:Version 11 introduces a native ARM64 engine, PEGRPARM64I.DLL, and ARM64 control flavors for the Winform and WPF interfaces on .NET 48, .NET 8, and .NET 10, and for the WinUI interface on .NET 10, together with ARM64 NuGet packages. ProEssentials now renders natively on ARM64 Windows devices, including embedded scenarios and native ARM64 development within Visual Studio. On an ARM64 machine, native ARM64 processes load PEGRPARM64I.DLL, while x64-emulated processes continue to use PEGRP64I.DLL; the two distinctly named engines coexist so each application loads the engine matching its architecture. IV. .NET 10 Support:All .NET interfaces (WinUI, WPF, Winforms) add a .NET 10 target, with .NET 10 NuGet packages and demo projects. The installed demos now include .NET 10 WinUI, WPF, and Winforms example folders in addition to the existing .NET Framework 4.8 and .NET 8 demos. V. .NET Framework (net48): One Build for x64 + x86 + ARM64The .NET Framework interface is the one that deploys to every Windows architecture from a single build. Because a .NET Framework AnyCPU assembly is pure IL rather than an architecture-fixed launcher, one compile runs natively as x64, x86, or ARM64 - so a single EXE and a single installer cover all three, with ARM64 selected through the project's Prefer native ARM64 option (.NET Framework 4.8.1). This AnyCPU flavor embeds all three native engines and binds the one matching the running process. v11 also ships explicit x64, x86, and ARM64 flavors that bind the real engine name (PEGRP64I.DLL / PEGRP32I.DLL / PEGRPARM64I.DLL) when you prefer a single-architecture build. The modern .NET (Core) interfaces behave differently: a .NET 8 or .NET 10 AnyCPU build produces a native launcher whose architecture is fixed at build time, so an x64 build runs x64-emulated - not native - on ARM64. This is standard .NET 5+ behavior, not specific to ProEssentials, so for those interfaces we recommend building and installing a per-architecture EXE (x64 and ARM64). They still offer self-contained AnyCPU packages: the .NET 8 AnyCPU embeds x64, x86, and ARM64 engines, while .NET 10 AnyCPU embeds x64 and ARM64 - so if you need x86 inside an AnyCPU package, choose the .NET 48 or .NET 8 flavor. VI. Modern Native Loading and Unified Licensing:Version 11 retires most of the long-standing AnyCpu practice of renaming the native engine to a single generic name (.NET 4.8 required this pattern). Instead, .NET8 and .NET10 use a runtime resolver to bind the engine reference to the real architecture-specific engine (PEGRP64I.DLL, PEGRPARM64I.DLL, or PEGRP32I.DLL) using the normal operating-system search order. For the self-contained AnyCPU flavors, the embedded engine is unpacked beside your application EXE when that folder is writable (the common case), and otherwise to a per-user cache at %LOCALAPPDATA%\<brand>\ProEssentials\<version>\<arch>\. The cache brand is taken from the new PeGlobal.CacheBrand property, else your application's AssemblyCompany, else "Gigasoft". Because the native engine self-reports its license state (a stamped engine is licensed, an unstamped engine runs in evaluation with a watermark), the same assemblies work for evaluation, development, and distribution without swapping files. VII. New Built-in User Experience (Menu and Dialogs):Version 11 adds a modern built-in user interface for the WinUI and WPF controls, and modernizes the Winform control's UX. This includes a native right-click context menu and a set of modern, resizable dialogs: Color, Font, Export (with live preview and a font-size slider), Print (with live preview plus printer, orientation, copies, style, and DPI selection), Text Export, and a new Titles dialog. Every installed .NET demo, from .NET 10 down to .NET Framework 4.8, opens with this new popup menu and dialog UX by default, so you can explore it immediately. If you prefer the legacy Win32-based menu and dialogs, set the control's UseWinformsUX (Winform), UseWpfUX (WPF), or UseWinUIUX (WinUI) property to false. The entire UX is fully localized. All 19 supported languages are embedded directly in the single control DLL, so there are no satellite assemblies or culture subfolders to distribute. VIII. New Properties:Version 11 adds only a handful of new properties, discussed here so you can adopt them without waiting on the individual reference pages; the full alphabetic Property, Method, and Event listing remains the authoritative reference for everything else. RenderPriority (WinUI): Controls how the WinUI control schedules its Direct3D/Direct2D render work, with values Auto, Low, Normal, and High. Auto (the default) keeps the interface responsive during interaction while protecting modal dialogs from render starvation; choose a fixed priority only when you need to override that balance. It is read at each render request, so it can be changed at any time, even mid-interaction. PeGlobal.CacheBrand (static string, AnyCPU flavor): Names the per-user folder used when a self-contained AnyCPU assembly must extract its embedded engine because the application folder is not writable. The path is %LOCALAPPDATA%\<CacheBrand>\ProEssentials\<version>\<arch>\. Leave it unset and the brand defaults to your application's AssemblyCompany, or "Gigasoft" when that is empty. Set it once at startup, before creating any chart. It is ignored by the architecture-specific x64, x86, and ARM64 flavors, which never extract an engine. UseWinformsUX / UseWpfUX / UseWinUIUX (bool, default true): Enable the new built-in menu and dialog UX described in section VII. Set the property for your interface to false to fall back to the legacy Win32 popup menu and dialogs. PeAnnotation.EnableWinUIDrawTable (WinUI, bool): Opts the WinUI control into a dedicated composition layer for real-time table annotations (PEdrawtable), so table overlays update efficiently without forcing a full re-render. Examples 028 and 030 demonstrate PEdrawtable in this mode. Localized date-axis strings: A set of engine strings that let the control render fully localized date axes, covering three-character month names, three-character and one-character day names, and the date separator character. The .NET controls apply these automatically as part of their localization, and they are also available to native (DLL/OCX/VCL) developers. IX. Localization:The .NET control DLLs are single-file and embed all 19 languages, eliminating satellite resource assemblies. The native engine renders localized date-axis month and day labels and separators, so localized date axes are handled end to end. The legacy v10 localization mechanism remains fully supported as well. MFC/C++ DLL, Delphi/Builder, and even .NET developers can continue to rely on the engine loading a separate resource-only DLL, as described on our resource files page. X. New Demo Examples and New WinUI Printing Example:Version 11's demo additions center on the new interface and target frameworks. The installer adds a WinUI demo project in the WINUI-C#.NET10 folder, .NET 10 editions of the Winform and WPF demos in the C#.NET10 and WPF-C#.NET10 folders, and WinUI editions of the high-performance flagship demos in the GigaPrime2DwinUI and GigaPrime3DwinUI folders. These sit alongside the existing .NET Framework 4.8 and .NET 8 demo folders, so you can compare the same charts across every supported interface and framework. Note the WinUI examples include a new WinUI printing example project that demonstrates WinUI's improved printing features. WPF's printing support was always lacking and/or very tedious to implement print preview. Now WinUI's printing easily supports print preview, a great addition to your WinUI-based software. XI. New to ProEssentials?If you are evaluating ProEssentials for the first time, the ProEssentials v10 News and ProEssentials v9 News pages are also worth a skim. Much of what those releases introduced remains central to the product today. |
