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).
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).
11 reporter: David Hilvert <dhilvert@auricle.dyndns.org>
14 creation_time: 2009-03-19 13:16:46.138065 Z
17 id: 6cd62e00a1fd77d98364811a284b205c9d3c6e0c
19 - - 2009-03-19 13:16:46.738962 Z
20 - David Hilvert <dhilvert@auricle.dyndns.org>
23 - - 2009-03-19 13:35:38.402723 Z
24 - David Hilvert <dhilvert@auricle.dyndns.org>
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>
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>
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
48 - - 2009-03-19 14:54:32.126035 Z
49 - David Hilvert <dhilvert@auricle.dyndns.org>
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
56 - - 2009-03-20 13:00:49.449698 Z
57 - David Hilvert <dhilvert@auricle.dyndns.org>
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>
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
76 - - 2009-03-20 20:32:14.963769 Z
77 - David Hilvert <dhilvert@auricle.dyndns.org>
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>
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>
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.