Right now, only the SurfaceRenderer exists, which is very basic and doesn't do anything specialized. The steps it takes to render are:
Create the final output texture object
Populate the CachedRenderRects collection based on the IScreenObject.Font
Runs Refresh on each render step.
If any render step signaled it was dirty, runs Compose on each render step (which generally draws the render step to the final output texture)
Runs Render on each render step to create draw calls that draws the object as a whole to the screen.
Specialized screen surfaces have different render steps, which may include removing the SurfaceRenderStep, but always includes adding another render step, such as the ControlsHostRenderStep or the WindowRenderStep (which draws the tinted background on modal windows).
Specialized renderers would make it easier for someone to create, for example, their own "Window" class that didn't inherit from SadConsole's version. But it would also mean that there would need to be some sort of IWindowRenderParameters interface the renderer could use, which would include things like the whole screen tint color.
Secondly, if say ScreenSurface used a new specialized renderer named ScreenSurfaceRenderer, the renderer could do all the steps required for rendering directly and avoid the RenderSteps collection completely. But this makes it incompatible with say Cursor or ControlsHost which inject their own render steps.
A new ComposedRenderer would be created that did exactly what the current SurfaceRenderer does. IComposedRenderParameters would be created which had a boolean for "seed the renderer with what screen surface does" which sets up the render steps exactly the same as SadConsole currently does. This allows someone to request the composed renderer but leave it blank for them to craft.
The parameters for the renderer could be sent on the Host.GetRenderer method and could be reset via a Renderer.SetParameters method.
Also, both Renderer and RenderSteps are part of IScreenSurface. However, RenderSteps is useless on its own and requires the Renderer. Should it be moved to Renderer? This would let the renderer validate it's a compatible step, or at least reject non-compatible steps?
Right now, only the
SurfaceRendererexists, which is very basic and doesn't do anything specialized. The steps it takes to render are:CachedRenderRectscollection based on theIScreenObject.FontRefreshon each render step.Composeon each render step (which generally draws the render step to the final output texture)Renderon each render step to create draw calls that draws the object as a whole to the screen.Specialized screen surfaces have different render steps, which may include removing the
SurfaceRenderStep, but always includes adding another render step, such as theControlsHostRenderStepor theWindowRenderStep(which draws the tinted background on modal windows).Specialized renderers would make it easier for someone to create, for example, their own "Window" class that didn't inherit from SadConsole's version. But it would also mean that there would need to be some sort of
IWindowRenderParametersinterface the renderer could use, which would include things like the whole screen tint color.Secondly, if say
ScreenSurfaceused a new specialized renderer namedScreenSurfaceRenderer, the renderer could do all the steps required for rendering directly and avoid theRenderStepscollection completely. But this makes it incompatible with sayCursororControlsHostwhich inject their own render steps.A new
ComposedRendererwould be created that did exactly what the currentSurfaceRendererdoes.IComposedRenderParameterswould be created which had a boolean for "seed the renderer with what screen surface does" which sets up the render steps exactly the same as SadConsole currently does. This allows someone to request the composed renderer but leave it blank for them to craft.The parameters for the renderer could be sent on the
Host.GetRenderermethod and could be reset via aRenderer.SetParametersmethod.Also, both
RendererandRenderStepsare part ofIScreenSurface. However,RenderStepsis useless on its own and requires theRenderer. Should it be moved toRenderer? This would let the renderer validate it's a compatible step, or at least reject non-compatible steps?