bugs/issue-6cd62e00a1fd77d98364811a284b205c9d3c6e0c.yaml

   1 --- !ditz.rubyforge.org,2008-03-06/issue
   2 title: Provide a method for avoiding duplicated renders (e.g., in the case of triangle:2 and fine:box:1,triangle:2 with identical inputs).
   3 desc: |-
   4   A reasonable approach to avoiding duplication would probably be to store a list of renderers within each
   5   context, and to refer to this, splitting renderers when necessary.  An alternative approach would be to
   6   add a synchronization type, perhaps encoded as a renderer type, and to use this to synchronize updates
   7   across renderers, keeping track of common substructures (somehow).
   8 type: :task
   9 component: libale
  10 release:
  11 reporter: David Hilvert <dhilvert@auricle.dyndns.org>
  12 status: :unstarted
  13 disposition:
  14 creation_time: 2009-03-19 13:16:46.138065 Z
  15 references: []
  16
  17 id: 6cd62e00a1fd77d98364811a284b205c9d3c6e0c
  18 log_events:
  19 - - 2009-03-19 13:16:46.738962 Z
  20   - David Hilvert <dhilvert@auricle.dyndns.org>
  21   - created
  22   - ""
  23 - - 2009-03-19 13:35:38.402723 Z
  24   - David Hilvert <dhilvert@auricle.dyndns.org>
  25   - commented
  26   - Note that it may be best to do this within client code (e.g., ALE, where such avoidance of duplication is already performed).
  27 - - 2009-03-19 13:55:08.450542 Z
  28   - David Hilvert <dhilvert@auricle.dyndns.org>
  29   - commented
  30   - |-
  31     Consider that the best approach for implementing this within library code
  32     (should such be desirable) might be to add a synchronization (or collection)
  33     type that is not encoded as a renderer type, but that, rather, returns a
  34     renderer given a specification string, and which requires that all updates to
  35     all renderers occur through the synchronization (or collection) type.  Such an
  36     approach should allow functionality roughly equivalent to that currently found
  37     within ALE, without requiring additional state storage within either context or
  38     renderer structures.  It should also allow for queueing, and should not require
  39     any sort of callback to client code for retrieval of image lists.
  40 - - 2009-03-19 14:36:04.167750 Z
  41   - David Hilvert <dhilvert@auricle.dyndns.org>
  42   - commented
  43   - |-
  44     Note that callbacks for image loading will probably be required for the case of
  45     Irani-Peleg rendering, so that having these in the case of a synchronization
  46     type (perhaps with loading occurring by frame number) would not be particularly
  47     undesirable.
  48 - - 2009-03-19 14:54:32.126035 Z
  49   - David Hilvert <dhilvert@auricle.dyndns.org>
  50   - commented
  51   - |-
  52     Note that, in the case of a render synchronization type, it might be desirable
  53     to have some means of disabling client updates to returned renderers (e.g., via
  54     a flag internal to the renderer type indicating that client updates should
  55     not be accepted).
  56 - - 2009-03-20 13:00:49.449698 Z
  57   - David Hilvert <dhilvert@auricle.dyndns.org>
  58   - commented
  59   - |-
  60     Note that treating the various rendering-related types as renderers might be
  61     most desirable, especially as this would allow for straightforward use of
  62     rendering-related operations (e.g., resizing and merging) without any additional
  63     API functions, and without the requirement for retaining constituent objects.
  64 - - 2009-03-20 18:32:40.381805 Z
  65   - David Hilvert <dhilvert@auricle.dyndns.org>
  66   - commented
  67   - |-
  68     Note, as a possible source of simplification, that duplication avoidance will
  69     probably be required only for the case of incremental renderers, and that,
  70     furthermore, Irani-Peleg rendering can probably proceed taking a final approximation
  71     as input, rather than taking any other renderer as a source (although this latter
  72     point might not be especially important).  In particular, there seem to be many
  73     possible sources of simplification of renderer operation, so that arranging renderer
  74     subspecies to interact with large numbers of other subspecies will probably not be
  75     necessary.
  76 - - 2009-03-20 20:32:14.963769 Z
  77   - David Hilvert <dhilvert@auricle.dyndns.org>
  78   - commented
  79   - |-
  80     Note that, rather than disabling individual renderer updates in the case of
  81     a synchronized set, it might be preferable to allow only updates based on indexes
  82     from a specified file set.  In particular, such an approach should allow
  83     compatibility between the use of synchronized sets and the use of incremental
  84     renderers as an input argument to Irani-Peleg renderers (as index synchronization
  85     could propagate from the Irani-Peleg renderer to the underlying incremental
  86     renderer under such a scheme).
  87 - - 2009-03-21 13:50:04.560424 Z
  88   - David Hilvert <dhilvert@auricle.dyndns.org>
  89   - commented
  90   - |-
  91     Consider that it might be useful to have Irani-Peleg renderers specified
  92     as (optionally) part of an ensemble, as this might be useful for rendering
  93     a number of results having variable degrees of Irani-Peleg processing.
  94 - - 2009-03-22 19:49:05.189402 Z
  95   - David Hilvert <dhilvert@auricle.dyndns.org>
  96   - commented
  97   - |-
  98     Consider that changes should probably never propagate upward a renderer tree,
  99     including from ensemble elements to the ensemble top level, but rather that
 100     synchronization status could be used to keep track of what frames have or haven't
 101     been handled for a given renderer instance.
 102 git_branch: