bugs/issue-fa1619a0e73f1630b3cc47ab81c8846b138a73b3.yaml

   1 --- !ditz.rubyforge.org,2008-03-06/issue
   2 title: Consider whether threshold parameters should remain associated with approx, or rather associated with rendering.
   3 desc: ""
   4 type: :task
   5 component: libale
   6 release:
   7 reporter: David Hilvert <dhilvert@auricle.dyndns.org>
   8 status: :closed
   9 disposition: :fixed
  10 creation_time: 2009-02-08 23:31:02.684984 Z
  11 references: []
  12
  13 id: fa1619a0e73f1630b3cc47ab81c8846b138a73b3
  14 log_events:
  15 - - 2009-02-08 23:31:04.012898 Z
  16   - David Hilvert <dhilvert@auricle.dyndns.org>
  17   - created
  18   - ""
  19 - - 2009-02-09 19:11:01.369586 Z
  20   - David Hilvert <dhilvert@auricle.dyndns.org>
  21   - commented
  22   - |-
  23     Considering that there might be a number of algorithms (generally rendering
  24     algorithms, but perhaps not specifically 2D incremental rendering algorithms)
  25     that might use definition and saturation thresholding parameters, and
  26     considering that, as with the case of multi-element alignment, any unified
  27     handling of such diversity would probably be tightly bound to some object close
  28     to the approximation data structure itself; consider that it would probably be
  29     most appropriate to maintain the threshold parameters within the approximation
  30     data structure, at least in an initial implementation.
  31 - - 2009-02-16 18:12:16.830309 Z
  32   - David Hilvert <dhilvert@auricle.dyndns.org>
  33   - closed with disposition fixed
  34   - Parameters under consideration have been re-associated, with rendering.