bugs/issue-778d1e3305e6cf6dd72d9836499e1788ca686f67.yaml

   1 --- !ditz.rubyforge.org,2008-03-06/issue
   2 title: Consider keeping 3D implementation in ALE initially, using either wrappers (e.g., d2::image over ale_image) or OpenCL for deprecated interfaces.
   3 desc: ""
   4 type: :task
   5 component: ale
   6 release:
   7 reporter: David Hilvert <dhilvert@auricle.dyndns.org>
   8 status: :unstarted
   9 disposition:
  10 creation_time: 2009-03-27 17:42:45.482605 Z
  11 references: []
  12
  13 id: 778d1e3305e6cf6dd72d9836499e1788ca686f67
  14 log_events:
  15 - - 2009-03-27 17:42:45.948075 Z
  16   - David Hilvert <dhilvert@auricle.dyndns.org>
  17   - created
  18   - ""
  19 - - 2009-03-27 17:52:43.565918 Z
  20   - David Hilvert <dhilvert@auricle.dyndns.org>
  21   - commented
  22   - |-
  23     Consider that, rather than wrapping d2::image over ale_image, it might be
  24     better to have image_rw return either d2::image or ale_image, according to
  25     request.
  26 - - 2009-03-27 18:04:29.155755 Z
  27   - David Hilvert <dhilvert@auricle.dyndns.org>
  28   - commented
  29   - |-
  30     An alternative to either wrappers or in-ALE OpenCL would be selective implementation
  31     of algorithms within Libale, an approach that reflects what is generally being done
  32     for the rest of the code, and which could also be applied to things like visp.
  33 - - 2009-03-28 05:18:27.499041 Z
  34   - David Hilvert <dhilvert@auricle.dyndns.org>
  35   - commented
  36   - |-
  37     Note, given support for nice things such as vectors in OpenCL, that a migration
  38     to Libale of the sort occurring in the 2D code might also be appropriate for
  39     3D.  As a very rough example of what might occur, a new type 'scene' could be
  40     added to Libale to subsume the sorts of operations currently occurring within
  41     the d3::scene class.