{"push_id":843955123,"size":1,"distinct_size":1,"ref":"refs/heads/master","head":"cf837e883809814af7389e4d7daa3a68b7ef02ca","before":"7a9b4aa93d4a6da4aab3a51398f4e75d7ae853b5","commits":[{"sha":"cf837e883809814af7389e4d7daa3a68b7ef02ca","author":{"email":"8e864f6891daea30887af7166abc194b98ea8641@tannerhelland.com","name":"Tanner"},"message":"pdUCSupport: new master user control support class\n\n(FYI: the old \"colorSelector\" user control is the guinea pig for this\ncommit.)\n\nI'm in the home stretch of PD's common control overhaul.  After more\nthan two years and ~30 custom-built user controls, I finally have a good\nnotion of what's required to construct a PD-grade user control.\n\nThe trouble, of course, is that a *lot* is required to make a user\ncontrol play nicely with all the things PD expects.  Flicker-free\npainting, automated caption support, high-resolution mouse input,\nsubpixel rendering, no GDI/GDI+ leaks, high-DPI support, minimalist\ndesigner rendering, etc.  These requirements lead to a lot of redundant\ncode across each UC, especially because I've tried to compartmentalize\nmost of these tasks into dedicated classes.\n\nI'm finally confident enough with designing PD's UCs that I think it's\ntime to wrap all these master capabilities inside a single, omnipotent\nsupport class.  This master class should support everything a user\ncontrol would ever want - including some low-level things, like\nautomatic back-buffer management - while also taking over duties for\nobnoxious shit like detecting designer mode and adjusting subclassing,\npainting, etc to match.\n\nTo that end, I've constructed a new pdUCSupport class, and wired it into\nPD's old colorSelector control for testing.  This class takes over a\n*lot* of user control duties, so it's quite an overhaul to convert an\nentire user control to it.  But I believe the end result is worth it: in\nthe case of the test ColorSelector control, 100+ lines of code were\nremoved, and a ton of messy responsibilities (like optimally synching\nbackbuffer size, or subclassing resize events) have been completely\nextracted from the user control.  This way, controls can focus purely on\ninteraction and rendering, instead of so much back-end fixes for tedious\ngarbage like VB's inability to handle high-DPI calculations correctly.\n\nAnyway, there are still some things to sort out on a case-by-case basis,\nbut an immediate benefit of this commit is reduced compilation time for\nthe project.  As each UC is moved over to this system, compilation time\nshould continue to drop.  I should also be able to greatly cut the GDI\nhandle count required by the program, since I can pool shared resources\nbetween controls (like font objects).\n\nI want to battle test this new approach a bit before commencing work on\na new pdListBox, as list boxes are arguably the nastiest control I need\nto build, given how many custom implementations are required throughout\nthe project.","distinct":true,"url":"https://api.github.com/repos/tannerhelland/PhotoDemon/commits/cf837e883809814af7389e4d7daa3a68b7ef02ca"}]}