add render notes

1 files changed, 19 insertions, 1 deletions

diff --git a/Development/Documentation/GlamorPerformance.mdwn b/Development/Documentation/GlamorPerformance.mdwn
index 4ab7453a..38a62ef0 100644
--- a/Development/Documentation/GlamorPerformance.mdwn
+++ b/Development/Documentation/GlamorPerformance.mdwn
@@ -40,7 +40,25 @@ GetSpans is irrelevant, you can't hit it unless you're using the mi blit routine
 
 ## Render
 
-TODO
+The Render implementation needs major work:
+
+0) Determine if the largepixmap code is salvageable or easily replaceable.
+
+Right now modification of the Render extension support is nearly impossible because of the largepixmap render support.  If we got rid of this it would be easy to hack on, but it may be that we need it for performance (For example, on Firefox's scaling of large photographs).
+
+1) Use GL_ARB_texture_view to reinterpret pixmaps as various sets of channels.
+
+Without this, Render ops with a2r10g10b10 or r5g6b6 will fall back to software because we only store pixmaps as either a8r8g8b8 or a8.
+
+This requires use of GL_ARB_texture_storage and therefore GL_ARB_sampler_objects.  See https://github.com/anholt/xserver/tree/glamor-sampler-objects
+
+2) Use the new program infrastructure for transformations.
+
+We do a ton of computation on the CPU for the coordinates of our Render ops. These are best done in shader code, instead.
+
+3) Accelerate trapezoids
+
+With modern GL, we should be just fine writing the trapezoids rendering in a shader, improving xlib-cairo path performance massively.  Today, we allocate in an memory pixmap, rasterize traps into it, then upload to GL and do a Composite from there.
 
 ## XVideo