1 files changed, 18 insertions, 0 deletions
diff --git a/Development/Documentation/GlamorPerformance.mdwn b/Development/Documentation/GlamorPerformance.mdwn
index beae11dc..027c451b 100644
@@ -6,6 +6,8 @@ The two bits of core GC state that tend to cause fallbacks are GCFunction and GX
We could probably accelerate both of the above if the GL(SL) below us has something like [[MESA_shader_integer_functions|https://www.opengl.org/registry/specs/MESA/shader_integer_functions.txt]] or [[EXT_framebuffer_fetch|https://www.khronos.org/registry/gles/extensions/EXT/EXT_shader_framebuffer_fetch.txt]].
+Composite clip walk could likely use [[EXT_window_rectangles|https://www.opengl.org/registry/specs/EXT/window_rectangles.txt]] instead of glScissor.
### Image ops
PutImage is implemented with TexSubImage2D, so is only accelerated for GXcopy operations. If LogicOp works, you could accelerate this by using a temporary texture and drawing through it to the destination.
@@ -20,10 +22,26 @@ GetImage falls back entirely for XYPixmap, and again, GL very wisely doesn't bel
### Geometry ops
+It's extremely difficult to want to reimplement the arc or polygon code directly in the shader, as neither one sees very much use even in legacy apps. We should profile to make sure the current approach of decomposing to spans on the CPU is "fast enough".
+The rectangle ops are probably about as perfect as they're going to get.
### Text ops
### Span ops
+SetSpans, like PutImage, operates on the texture so can't accelerate non-GXcopy operations.
+FillSpans might benefit from an alternate calling convention, where rather than being passed a span list the caller asks the driver to allocate the span storage, fills that in, then calls Set or Fill. This would let us eliminate the copy into the vbo and just store there directly.
+GetSpans is irrelevant, you can't hit it unless you're using the mi blit routines, and we're not.