Add some descriptions to new classes

4 files changed, 14 insertions, 11 deletions

diff --git a/Source/Core/VideoCommon/AbstractGfx.h b/Source/Core/VideoCommon/AbstractGfx.h
index be9708c12f..e59270871c 100644
--- a/Source/Core/VideoCommon/AbstractGfx.h
+++ b/Source/Core/VideoCommon/AbstractGfx.h
@@ -39,6 +39,11 @@ class AsyncShaderCompiler;
 
 using ClearColor = std::array<float, 4>;
 
+// AbstractGfx is the root of Dolphin's Graphics API abstraction layer.
+//
+// Abstract knows nothing about the internals of the GameCube/Wii, that is all handled elsewhere in
+// VideoCommon.
+
 class AbstractGfx
 {
 public:
diff --git a/Source/Core/VideoCommon/OnScreenUI.h b/Source/Core/VideoCommon/OnScreenUI.h
index ea8eeb6630..e90d1c2132 100644
--- a/Source/Core/VideoCommon/OnScreenUI.h
+++ b/Source/Core/VideoCommon/OnScreenUI.h
@@ -16,6 +16,8 @@ class AbstractPipeline;
 
 namespace VideoCommon
 {
+
+// OnScreenUI handles all the ImGui rendering.
 class OnScreenUI
 {
 public:
diff --git a/Source/Core/VideoCommon/Present.h b/Source/Core/VideoCommon/Present.h
index 5e84d5aada..fb4799898c 100644
--- a/Source/Core/VideoCommon/Present.h
+++ b/Source/Core/VideoCommon/Present.h
@@ -23,6 +23,8 @@ namespace VideoCommon
 class OnScreenUI;
 class PostProcessing;
 
+// Presenter is a class that deals with putting the final XFB on the screen.
+// It also handles the ImGui UI and post-processing.
 class Presenter
 {
 public:
diff --git a/Source/Core/VideoCommon/RenderBase.h b/Source/Core/VideoCommon/RenderBase.h
index 0468681e21..d2e0036563 100644
--- a/Source/Core/VideoCommon/RenderBase.h
+++ b/Source/Core/VideoCommon/RenderBase.h
@@ -1,15 +1,6 @@
 // Copyright 2010 Dolphin Emulator Project
 // SPDX-License-Identifier: GPL-2.0-or-later
 
-// ---------------------------------------------------------------------------------------------
-// GC graphics pipeline
-// ---------------------------------------------------------------------------------------------
-// 3d commands are issued through the fifo. The GPU draws to the 2MB EFB.
-// The efb can be copied back into ram in two forms: as textures or as XFB.
-// The XFB is the region in RAM that the VI chip scans out to the television.
-// So, after all rendering to EFB is done, the image is copied into one of two XFBs in RAM.
-// Next frame, that one is scanned out and the other one gets the copy. = double buffering.
-// ---------------------------------------------------------------------------------------------
 
 #pragma once
 
@@ -32,8 +23,11 @@ struct EfbPokeData
 };
 
 // Renderer really isn't a very good name for this class - it's more like "Misc".
-// The long term goal is to get rid of this class and replace it with others that make
-// more sense.
+// It used to be a massive mess, but almost everything has been refactored out.
+//
+// Most of the remaining functionality is related to EFB and Internal Resolution scaling
+//
+// It also handles the Widescreen heuristic, frame counting and tracking xfb across save states.
 class Renderer
 {
 public: