Cytoscape Wiki|
← Revision 1 as of 2008-07-04 18:00:25 →
Size: 1613
Comment: current notes about pluggable renderers
|
Size: 1917
Comment: some notes
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 4: | Line 4: |
|
== Immediate TODO == * read viewmodel api, structure proposals (["Cytoscape_3.0/ViewModelDiscussions"] and cyto-staff) * re-read vizmapper architecture |
|
| Line 17: | Line 23: |
| (Try to simplify vizmapper API at this step, creating and applying custom visual style are apparently not simple enough; see VisualStyleSimplification and ... (there was one page on wiki where this was mentioned but I can't find it now.)) | (Try to simplify vizmapper API at this step, creating and applying custom visual style are apparently not simple enough; see ["Visual Style Simplification"]) |
| Line 29: | Line 35: |
|
* |
|
| Line 34: | Line 38: |
|
* good description of visual mapping framework: ["Visual_Mapping_System_Guide"] * eclipse's "Open Call Hierarchy" is pretty neat |
|
| Line 35: | Line 41: |
| * good description of visual mapping framework: ["Visual_Mapping_System_Guide"] |
It is only called from render.stateful GraphRenderer.renderGraph() which is basically the inner loop Basically these are the places where large refactorings will be done. |
This page collects my notes about the crazy "pluggable renderers" idea I posted to the cytoscape-staff mailling list.
The current plan is to produce a proof-of-concept prototype by the cytoscape retreat in Toronto. (which means in one week)
Immediate TODO
- read viewmodel api, structure proposals (["Cytoscape_3.0/ViewModelDiscussions"] and cyto-staff)
- re-read vizmapper architecture
Implementation plan
- only do nodes at first
- don't care about benchmarking, at first
- don't care about OSGi framework, at first
Do in following order:
refactor GraphGraphics and GraphRenderer to call separate NodeRenderers for rendering. No vizmap changes yet, and only original renderers/ nodeshapes kept
- refactor vizmapper to be able to use pluggable 'mappable visual attributes'. (Try to simplify vizmapper API at this step, creating and applying custom visual style are apparently not simple enough; see ["Visual Style Simplification"])
- Lift some noderenderers from other code (ideally the following: pie nodes, custom bitmap and custom vector graphic image)
- use OSGi for pluggability (this will be about simply figuring out OSGi and how to use it for renderers-as-service)
- do some benchmarks to show that all this didn't make rendering slow as molasses.
Things to figure out
- place in model / viewmodel / view division (I'll have to study the current plan for the viewmodel api)
Notes about current rendering architecture
- good description of visual mapping framework: ["Visual_Mapping_System_Guide"]
- eclipse's "Open Call Hierarchy" is pretty neat
render.immed is only GraphGraphics, which is only a collection of methods It is only called from render.stateful GraphRenderer.renderGraph() which is basically the inner loop Basically these are the places where large refactorings will be done.