Update comments to reflect the current reality.shatter-2

1 files changed, 18 insertions, 27 deletions

diff --git a/miext/shatter/shatter.c b/miext/shatter/shatter.c
index 8963383e2..a9b864b49 100644
--- a/miext/shatter/shatter.c
+++ b/miext/shatter/shatter.c
@@ -24,29 +24,26 @@
  */
 
 /*
- * This implements GC, Render, and Xv polydispatch for pixmaps with
- * disjoint allocation.
+ * This implements GC polydispatch for pixmaps with disjoint allocation.
  *
  * If all CRTCs for a GPU are required to scan out of the same buffer,
- * the driver may need to constrain the size of this allocation in order
- * to be able to do accelerated rendering.  For example, you may be able
- * to scan out up to a width of 2k pixels on each of two CRTCs, but your
- * blitter is also limited to a pitch of 2k; so you can't have a solid
- * allocation that's 4k pixels wide, because your blitter won't be able
- * to work with it.  Instead you want separate allocations for each CRTC,
- * and to iterate rendering across each one.
+ * then you're artificially limited in how big your scanout size can be.
+ * Each CRTC might have a pitch limit of 2k, but if they're bound to the
+ * same buffer that's an effective total pitch limit of 2k.  If you
+ * shatter the root window pixmap, you can have each CRTC pointing at
+ * different pixmaps, and this code will handle iterating rendering across
+ * each one.
  *
  * Likewise, your acceleration hardware is almost certainly less capable
  * than the full coordinate space that X makes legal.  If you shatter the
  * pixmap's storage, you can work around this.  Woo!
  *
- * This code cribs heavily from the DMX multiplexing code.  We depend on
- * the Composite extension, in that thepixmaps are given non-zero
- * screen_[xy] even though they're not (necessarily) redirected windows.
- * The rendering layers under us need to be able to cope with that, but if
- * all else fails that's what miext/cw is for.
- *
- * #if 0
+ * We depend on the Composite extension, in that the pixmaps are given
+ * non-zero screen_[xy] even though they're not (necessarily) redirected
+ * windows. The rendering layers under us need to be able to cope with that,
+ * but if all else fails that's what miext/cw is for.  We also rely on the
+ * lower layers to clip their rendering to the pixmap's extents, but again,
+ * this had better be true anyway.
  *
  * Possible future work:
  *
@@ -59,13 +56,7 @@
  *   necessary?  How awful would it be to just validate the parent GC against
  *   the CRTC pixmap?
  *
- * - Right now the code assumes one of two states: either all CRTCs share
- *   an allocation, or there's no sharing at all.  Most hardware right now
- *   only has two, so it's not a huge problem, but when that changes we'll
- *   want to revisit the CRTC walk loop.  Right now it's "for each CRTC",
- *   it should instead be "for each CRTC pixmap".
- *
- * - Because CRTC pixmaps have screen coordinates, we don't need to
+ * - Because shard pixmaps have screen coordinates, we don't need to
  *   translate primitive geometry before handing it to the lower layers.
  *   However we do have to copy it aside before every dispatch because
  *   we can't depend on the lower layers not to modify it.  That would be
@@ -76,13 +67,13 @@
  *   sending them lower in the stack, but at least for the core X primitives
  *   this is unlikely to ever make real world usage better.
  *
- * - Implement XV shatter too.
- *
  * - Screen hooks just suck.  You basically need each shatter consumer to
  *   supply its own GetImage, since you can't get a "scratch screen" the way
- *   you can get a scratch GC.
+ *   you can get a scratch GC.  This applies to Get{Image,Spans}, and the
+ *   Render and Xv paths.
  *
- * #endif
+ * - Copy{Area,Plane} might do... interesting things if the shards logically
+ *   overlap.  Particularly if the rop is something other than Src.  Hm.
  */
 
 #ifdef HAVE_DIX_CONFIG_H