Make shaders not follow padding; consider moving padding into the renderer

[Acurisu]

Description of the new feature/enhancement

I'm not sure whether this is by design or not but making the shader only render inside the padded area makes it, in my opinion, look less good. I like my text to be padded without having my shaders cut off where the text area ends.

For smaller paddings one could currently just move the texture a little by sampling at an offset but this will break highlighting at a certain point.

[DHowett]

You're right to call this out. We're not in a good place to handle this right now.

Back when we implemented padding, we had the debate about handling it while rendering or outside the renderer.

The downsides of doing it inside the renderer include that we need all hit testing (click position mapping from pixel to glyph cell) to involve the renderer, which is not a particularly lovable architecture.

The upside, of course, is that it would have made this a non-issue. 😄

I do think we'll need to do something here.

[DHowett]

Alright, I've been working on this for a while! It's promising.

I wanted to tap in @mrange to ask a question.

I want to finish up the v1 interface for the constant buffer we pass to the pixel shader.

Right now, it contains the following...

float time; // fractional seconds since the shader last "started"
float scale; // display scale as a fraction; 1.0 is 100%
float2 resolution; // **size of the addressable character viewport in pixels**
float4 background; // color of the background fill, if there is one

I've "learned," or at least observed, that passing something to the pixel shader that is in viewport pixel coordinates makes for overcomplicated shader code.

@lhecker suggested that once we factor in padding, we might want to revisit how we pass that stuff to the shader.

• Is the resolution in pixels useful?
  • Should it be the resolution of the entire rendered surface, rather than just the viewport? This would include gutters and padding
• Is it valuable to have the viewport?
  • The viewport is smaller than the entire rendered area, due to padding and gutters.
  • Should it be in UV coordinates?
  • From the viewport, you can derive the space occupied by the padding.
  • However, you may not be able to derive the gutters.
  • Is it meaningful to differentiate the padding from the gutters?
• What about the cursor position and size? And, type? It takes up a full cell, but it has different appearances...
  • UV? Pixel?
• What else should we include? There's a request in Expose time, date, mouse, ideally CPU / GPU / memory utilization to custom HLSL shaders #9468 for system statistics, but I'm wary of introducing them at the renderer layer. The mouse position could be useful.

[lhecker]

Is it meaningful to differentiate the padding from the gutters?

@DHowett I'm not sure the distinction is obvious, since OP refers to what you call "gutters" as the "padding" already. 😅 Personally speaking, it's my first time realizing that you consider them distinct. I considered the extra padding to belong to the gutters so far (= gutters aren't always uniformly sized).

The "gutters" are the 8px margin/padding around all 4 sides of the viewport. (And unless I misunderstood) Dustin is referring to the extra "padding" on the right and bottom sides when the terminal window is maximized. Here's the difference (left is windowed, right is maximized):

Edit: Or... Wait. Did I mix gutters and padding up? Ugh I always mix them up. I call them both just the "margin", because that's how CSS would call it.

---

Couple more ideas: We could "standardize" the names of the parameters. That way we could dynamically build the constant buffer with whatever information the shader wants and it would still work if we add more fields in the future.

It'd be great if we could allow for compute shaders too, since those require an entirely different setup, but are way more flexible. I suspect that true shader freedom requires a more complex setup with separate metadata (but I'm also not an expert with D3DReflect so maybe it is possible to cram all metadata into the shader files).

[mrange]

Some random thoughts. Resolution is very often used. One use is to figure out the aspect ratio. Another common use is to figure out the “pixel” size for anti aliasing. In general I think the more info available to the shader to the more interesting things you can do so know the viewport size and the full size is valuable. I think the UV coords should be in range (0,0) -> (1,1) for the full texture implying that viewport size is then smaller than full size. (risk of breaking changes here). I would love more information being available. The more info, the more you can adopt the rendering to what’s happening in the shader. OFC there’s a risk of a very wide API. Since it’s sounds like you are getting to a v1 of the shader thing which is great I think some thoughts around how to make the API expandable could be good. For example if you like to add more values later. I don’t know exactly what is the best way to do that with DX shaders. Also I think it should be stated what version of the shader language are in use. Perhaps even better support multiple versions (here GLSL has a pretty sweet idea that I don’t think works in HLSL). Here’s some thoughts I had earlier of things to be accessible from shader (no thoughts given on the difficulty to do it): Error state (command completed successfully or not, probably should include a timestamp saying how old the state is to allow for animations) Mouse coord ((0,0) --> (1,1) range I think) Cursor coord (in cell size I think make sense) Date & Time Font cell size Previous frame Background image/video Desktop image from behind the window (to allow for your own windows transparency effects) Current sound + FFT (think winamp like visualizations) Mårten PS. Some thoughts on other improvements I was thinking about from before. Mentions it here because now I am stuck with 4KiB intro making 😊. (No thoughts given on complexity to implement ) Reload on shader source change (would be really cool sitting in Vim editing a shader and save it reloads in the background! Better report of error messages (render error message in the texture and show it as a background?) Could make WT a choice for shader live coding jams!). Support multistep shaders Vertex shader support + instancing (This is probably complex to get good) Timer should belong to tab not texture (Reloading shader loses the timer state, feels not right)

[Welding-Torch]

Hi there, would love to see an update on this as the gutters/padding/margins are still breaking the immersion of using some shaders 👍