Dev:Software roadmap

A software roadmap is in the process of being developed. If you would like to lobby for specific functionality to be implemented sooner than what is stated, please discuss it in the talk page.

Since the roadmap isn't finished yet, here is an unsorted list of things that I plan to implement:

Roadmap

Under-the-hood changes

• Redesign the render target class
  • current implementation doesn't handle large images very well
• migrate API to be more language agnostic
• Add support for arbitrary multiple color channels
• Add support for customizable mixing gamma per canvas
• Start migrating toward a script-friendly API
• Implement garbage collection of synfig nodes
• Re-write or replace the "Simple Text" layer for proper font support. Current implementation is gnarly.

Optimizations

• Change the way surfaces are stored in memory from chunky to planar. This alone should provide significant speed improvements, as well as pave the way for future hardware optimization. (like Apple's new CoreImage)
• Support for arbitrary color channels
• Support for customizable color mixing gamma

User Interface

• Re-write the canvas properties dialog, as it is currently too awkward and confusing
• Reimplement the draw tool so that it is actually useful
• Rewrite state_draw to handle simultaneous creation of region/bline/curve gradient, like state_region. (Snap)
  • Since that's basically recopying code, try to refactor this functionality into its own module somewhere? (Snap)

TO-DO

(Synfig-Studio)

• Objectify Synfig-Studio's representation of Synfig-Core's types
  • Build datatypes for Studio visualisations
    • Implement 'shell' datatypes for existing Synfig types.
      • Studio Layer datatype
        • Create initial definition of this datatype and add to project
        • Insert code into selection functions to store references to ducks on "studio layer" type when selected.
        • Add functions to "studio layer" type to select specific ducks on layer.
• Rework and extend layer-search system.
  • "The layer should provide a virtual function for determining if the layer is clickable at the given point or not -- a bool. This will allow you to implement different types of traversals/filtering" -- darco, on IRC
  • "Actually, I think there will still need to be a virtual function which handles the traversal case, and have it use the bool function... Things can get complicated if you had a layer that had two canvas parameters" -- darco, on IRC
• Build a public interface for DuckMap (duckmatic.cpp/208)

(From the code)

src/gtkmm/cellrenderer_timetrack.cpp (161)

Add in RangeGet so it's not so damn hard to click on points

src/gtkmm/cellrenderer_timetrack.h (104)

Make multiple... on both time and value select...

src/gtkmm/duckmatick.h (208)

need a public interface for DuckMap

src/gtkmm/widget_timeslider.h (78)

Fill out blue pill stuff

src/synfigapp/blineconvert.cpp (496)

Tolerance should be set based upon digitization resolution (length dependent index selection)

src/synfigapp/blineconvert.cpp (584)

Must be sure that the break points are 3 or more apart then must also store the breaks which are not smooth, etc. and figure out tangents between there

Needs //Comment// Doc

src/gtkmm/app.h (file header brief)

src/gtkmm/canvasview.h (546)

rebuild_ducks()

src/gtkmm/cellrenderer_timetrack.h (142)

property_enable_timing_info_;

src/gtkmm/duck.h (79)

class Duck

src/gtkmm/duck.h (155)

set_tangent(bool x)

src/gtkmm/duck.h (158)

get_tangent()

src/gtkmm/duck.h (175)

set_type(Type x)

src/gtkmm/duck.h (178)

get_type()

src/gtkmm/duckmatic.h (367)

set_type_mask(Type x)

src/gtkmm/duckmatic.h (370)

get_type_mask()

src/gtkmm/duckmatic.h (388)

Duckmatic::Push

src/gtkmm/duckmatic.h (407)

Duckmatic::Bezier

src/gtkmm/duckmatic.h (421)

Duckmatic::Stroke

src/gtkmm/instance.h (file header brief)