bugs/issue-8070953002a30b1d6faaba9ce23d615804252165.yaml

   1 --- !ditz.rubyforge.org,2008-03-06/issue
   2 title: Determine what patterns of pixels to support, and how to support them (see also {issue cd8cda126db604feda8a481b2022490311624cb9}).
   3 desc: |-
   4   For loading and caching performance, the arrangement of pixels in memory could
   5   be important.  Determine what mechanism should be used for pattern
   6   determination (e.g., allowing client code to select a pattern), and what sorts
   7   of patterns should be provided for (e.g., one of a fixed set, or perhaps based
   8   on provided client code).  Obvious approaches would include interleaving digits
   9   (e.g., bits) of horizontal and vertical coordinates, or other mapping providing
  10   a monotonic relationship between each coordinate and the resulting index.
  11 type: :task
  12 component: libale
  13 release:
  14 reporter: David Hilvert <dhilvert@auricle.dyndns.org>
  15 status: :unstarted
  16 disposition:
  17 creation_time: 2009-02-22 10:10:45.773096 Z
  18 references: []
  19
  20 id: 8070953002a30b1d6faaba9ce23d615804252165
  21 log_events:
  22 - - 2009-02-22 10:10:46.821539 Z
  23   - David Hilvert <dhilvert@auricle.dyndns.org>
  24   - created
  25   - ""
  26 - - 2009-02-22 10:16:24.980467 Z
  27   - David Hilvert <dhilvert@auricle.dyndns.org>
  28   - commented
  29   - |-
  30     Keith Packard comments briefly somewhere on-line regarding the approaches to
  31     pixel patterns (via bit swizzling) taken in the Intel video drivers.  If I
  32     recall correctly, he describes two patterns used, one more square and one more
  33     rectangular, each having something on the order of 300 pixels in each
  34     dimension.
  35 - - 2009-02-23 11:55:28.207865 Z
  36   - David Hilvert <dhilvert@auricle.dyndns.org>
  37   - commented
  38   - |-
  39     A reasonable approach might involve two API functions available to client code,
  40     one for setting the format without changing any memory structures, and one for
  41     re-arranging the memory structure to reflect a new format.  E.g.,
  42
  43     ale_image_set_pattern(...)
  44
  45     ale_image_repattern(...)
  46
  47     In this way, details regarding how patterns are represented could be left for
  48     later.  (In particular, integration with ALE could proceed mostly independently
  49     of API and implementation of this feature.)
  50 git_branch: