Hi José,
I have refactored Tiko to use GDI+, but now I want to pursue moving everything to DirectWrite (for text) and Direct2D (for graphics). I see that AfxNova has both, but before I do anything I wanted to check with you to ensure that you are confident that the AfxNova implementation is solid enough in its current state.
I have all my text and graphics centralized in a clsDoubleBuffer.inc class so going from GDI to GDI+ was relatively uneventful. I am expecting that the switch to DirectWrite and Direct2D would be similar. Actually, since Direct2D already does buffering, then a lot of my existing class can be simplified.
I have refactored large portions of Tiko to move just about everything GUI related out into individual reusable custom controls. CListBox, CTextBox, CSplitter, etc... Each of those controls use the clsDoubleBuffer for rendering so the refactor should only have to touch the custom controls and not any additional code lying around inside Tiko.
Thanks!
I have a Claude Code Max subscription so I decided to go ahead and do a refactor test on one of my custom controls using the new technologies. When it's finished, I'll post the results here. It may be awesome, or it may crash and burn, but either way it will be a good test of your AfxNova implementation.
After 4 hours of extensive A/B comparison tests between GDI, GDI+, and D2D/DirectWrite, the decision became clear that D2D/DirectWrite was feasible and preferable especially on new display technologies like 4K monitors and high dpi settings. I have 11 custom controls that are being refactored and then re-integrated into Tiko on the Development branch. The end result will be better antialiasing for lines and curves and better text spacing. Effects such as alpha blending, shadows, etc is much easier to do and the overall display will look more like a GUI from this century. :-)
I know that AI gets a huge bad reputation and I agree with that 100%, however there's a HUGE difference between using the AI tooling to work alongside you to develop detailed design and implementation plans and then refactor, versus the commonly seen memes of the vibe coder slop. As an experienced developer, I am finding AI to be incredibly helpful and has made me more more productive and it has only been 1 week at this point. Moreover, being able to iterate and build new things and fix old problems is very motivating whereas in the past if I hit a dead end problem it would be demoralizing knowing that I'd be a week bogged down in debugging, etc. It has kind of made programming fun and exciting again. I can see why the whole script kiddie slop generating scene is so despised, but I also see the other side where it provides value to those who know how to program.
For completeness, I am using Claude Code so it is very specific for coding. What is surprising is that the more I use it to code in FreeBasic, the more it learns. It keeps all it's memories, best practices, gotchas, in files like Learnings.md and the overall CLAUDE.md files so every new project gets more efficient, fast, and thorough.
It's hard to put the experience into words in a post, but it's like having an experienced 10x engineer beside you rubbing your shoulders as you program. It has been very rare that I've experienced any AI hallucinations. For the most part, everything that has been discussed, planned, and refactored has been solidly built on proven and known WinAPI concepts.
I may feel different about all this tomorrow, but for now I am pleasantly surprised so I can't blindly dismiss the benefits at this point.
I hope I've done the translations right. Direct2D headers, especially DirectWrite, are a real nightmare. They contain functions that aren't functions at all, but rather disguised procedures, and their use of "using" to resolve methods with the same name in inherited interfaces. They call it "modern C++".
You must have done an amazing job because so far there hasn't one error attributed to your header file conversions! 8)
The D2D/DW refactor did produce a working Tiko, however, there was one main issue that could not be resolved so I have reverted back to the GDI+ version (which itself is a big win over the GDI version that the current release version of Tiko uses).
The problem was incredibly sluggish splitter controls. As the splitter moved, the associated panels would resize in real time per MouseMove. With GDI and GDI+, the screen updates were very smooth, but with D2D it was a disaster. Lots of screen tearing and major stuttering sometimes lasting a half second. Various workarounds were tried but ultimately this whole D2D experiment failed for my use case.
QuoteThat sluggishness is a classic bottleneck in Direct2D UI controls. Resizing Direct2D render targets or DXGI swap chains on every WM_MOUSEMOVE event is notorious for causing stutter, micro-freezes, and heavy CPU/GPU overhead.
Direct2D itself is hardware-accelerated and fast, but destroying/reallocating render buffers or resizing DXGI swap chains on every single mouse tick forces expensive GPU allocations and sync stalls.
There's a lot more technically going on under the hood but in applications with lots of D2D windows and large surfaces to resize and redraw on every MOUSEMOVE, you end up with huge stuttering. It's a deal breaker for me.