Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
Refactor GUI rendering: Add documentation and name `Viewport` consistently #8257
This will need fixups, because the commit checker won't let me indent a nested #define.
Hash mark must go in first column, as per https://wiki.openttd.org/Coding_style#Other_important_rules
Since they are only ever called with an int and a (int)uint; the templating seems completely unnecessary and redundant.
This reverts commit 8652a4d. This is necessary to aid in the cherry-picking of commits from JGRPP.
…g window list. This is to speed up marking all viewports dirty, which is done very frequently.
…acked for later redrawing Track dirty viewport areas seperately form general screen redraws. Maintain a dirty block grid per viewport, with a smaller block size. Use even smaller block size in viewport map mode. Use a rectangle array for general screen redraws instead of a block grid. Add a dirty bit to windows and widgets, to simplify the common case of repainting a whole window or widget, without catching neighbouring windows or viewports.
AddDirtyBlocks is an internal implementation detail of SetDirtyBlocks, and its name should reflect that.
The viewport cache is transparently managed by the ViewportData struct, and memory associated with the viewport and cache is automatically managed using smart pointers.
When I said split the viewport rename out into a separate PR, I meant that it should precede it and have nothing to do with the GUI rendering PR. Currently this just serves to bloat the size of the whole PR, making changes to code you've just added. And make it more difficult to review, since you've basically just duplicated the PR 3 times over.
So the renaming of
I'm not really sure what you want me to do. I've split the PR into three separate branches so they can be reviewed separately. Clearly, they can't all be based on the same version of