diff options
| author | Hans-Christoph Steiner <eighthave@users.sourceforge.net> | 2005-12-15 07:26:47 +0000 |
|---|---|---|
| committer | Hans-Christoph Steiner <eighthave@users.sourceforge.net> | 2005-12-15 07:26:47 +0000 |
| commit | 37b6643df2df7d784a31ca73f7bb90dc109c2401 (patch) | |
| tree | a8664e5adcfcb60cae136063d627549ecb76619b /TODO.EXP | |
| parent | c50ce0e0217ea07e2d450add2ab29cecea66fa96 (diff) | |
removing PDP source (except debian files) before import of PDP 0.12.4
svn path=/trunk/externals/pdp/; revision=4217
Diffstat (limited to 'TODO.EXP')
| -rw-r--r-- | TODO.EXP | 58 |
1 files changed, 0 insertions, 58 deletions
diff --git a/TODO.EXP b/TODO.EXP deleted file mode 100644 index f3d1955..0000000 --- a/TODO.EXP +++ /dev/null @@ -1,58 +0,0 @@ - -experimental stuff - -todo: - -* modify 2D rotation to be used as arbitrary rotation (givens) -* add 3D rotation -* frame rate limited delay line (burst delay?) -* optimize resampling code (mipmapped packed 16bit format?) - - -* cache slicer - -pdp_slice_cut & pdp_slice_glue seem to have a significant impact on performance -for long chains with simple (memory rate limited) operators. especially when a lot -of passive packets are involved. todo: make a vertical slicer + mmx transpose object -to use this for horizontal and vertical processors too (vertical processors: more efficient -because of alignment). find out why this doesn't work in threads + think about a possibility -to do first layout a buffer structure, and then do incremental processing (outside of pd/pdp: -for constructing optimized signal processors using some kind of intermediate language -and automatic slice dimension selection) -NOTE: solve this as a forth script for specific abstractions. - -* new image packet types - -*) PDP_IMAGE_MCHP - -multi channel stuff. this packet type is to solve some problems with the subsampled -chroma planes in PDP_IMAGE_YV12. although it is fast, it is best to have an equally -sampled, arbitrary number of channels image type available. - - -*) PDP_IMAGE_PCK4 - -the main reason for this package type is in resampling code to have single pixel -access mmx routines. but is it worth it? probably not.. mipmap image packet for resampling? - - -* new vectors, matrices & gsl packets - -general matrix math is a nice thing to have. wrapping gsl is a possibility. it can use -atlas for fast matrix math. finish better type handling first. - - -* opengl -> see also opengl/TODO - -move opengl stuff to dpd. -todo: -- think about pbufs / textures : isolate system specific stuff - - -* better type handling - -core is in place. todo: -- better (tree) search algorithm (breadth first + cost) -- add more converters - - |