From: address@nospicedham.not.available   
      
   Terje,   
      
   > One key issue is that you can generate all those classifications in   
   > parallel, so it could all be done in a cycle or two, replacing a bunch of   
   > distributed/replicated if (a <= b) tests.   
      
   I did not think of that, but that is indeed a case in which it could/would   
   matter (clipping both endpoints in parallel would than be another big   
   speed-up).   
      
   I do not see anything in/to the algorithm about such an intention though.   
   Also, AFAIC most environments upto rather recently where single-core (and   
   the algorithm was created back in 1967).   
      
   > Absolutely right, but it still helps: If we number the zones from 0 to 8,   
   > top left to bottom right, and neither end point is in the first (0..2)   
   > row, then we can skip all clip tests against the top of the frustrum.   
      
   Yes, thats the method used in the pseudo-code.   I don't think that that   
   bit-test will be much, if any shorter than the comparision of two values   
   though (assuming that the coordinates fit in the processors registers) .   
      
   In short, only the first creation of that zone bitmask (instead of four   
   times two coordinate-against-boundary comparisions) seem to weigh positivily   
   against the total time spend.  In the other cases a comparision of two   
   values could well be shorter than a regeneration of that zone bitmask and   
   the subsequently needed bit-test.   
      
   Hmm... Just thought of using the gathered zone bits as an index in a   
   jumptable to different boundary-compare sequences. As you said, a line which   
   starts in zone 0 (and is not trivially rejected) only needs to compare with   
   the top and left boundaries.     On the other hand, thats a lot of   
   duplicated code just to remove (the opposite) two boundary checks ....   
      
   > I believe my own code ignores the order clips should occur in   
      
   So does mine.  And as you said, it works ok that way (test have not shown   
   any glaring problems with it).   
      
   > I'm assuming this was intended for HW implementation where it is easy to   
   > have enough parallel resources to perform all those operations more or   
   > less at the same time.   
      
   Yes, thats is an explanation that makes sense.  Thanks for that.   I thought   
   I was going mad here. :-|   
      
   > With modern SIMD hardware we also want as many of the   
   > comparisons to happen at the same time as we can manage.   
      
   With modern hardware there is a good chance I can just tell the GPU what I   
   want to have happen and than leave the rest upto it. :-)   
      
   Regards,   
   Rudy Wieser   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)