Difference between revisions of "Org.simantics.g2d.feature"
m |
|||
Line 57: | Line 57: | ||
== Dependencies == | == Dependencies == | ||
− | * cglib | + | * cglib 2.2 ([[svn:2d/trunk/net.sf.cglib]]) |
+ | * org.objectweb.asm (3.2) | ||
= Releases = | = Releases = |
Revision as of 12:28, 6 October 2010
org.simantics.g2d feature (SVN) contains the Simantics 2D graphics framework.
Contents
Introduction
Concepts
- 2D rendering API
A rendering API offers the fundamental rendering operations needed to produce an image on-screen or off-screen.
Examples:
- 2D toolkit
A 2D toolkit is a component that works on top of a rendering API to provide a set of ready-made widgets or controls and the facilities to lay them out to eventually form graphical user interfaces. Toolkits provide an event handling mechanism to enable interaction between the user and the UI. Toolkits also tend to support the creation of custom widgets.
Examples:
- 2D framework
We consider a 2D framework to be a component that works on top of a rendering API and possibly a toolkit to provide a package for clients to make it easier for them to build different kinds of applications. The motivation, requirements and design of a framework all gear it to fit certain kinds of applications. A single framework is generally not the best for everything.
Boundary Conditions
Let's review the boundary conditions we're working under:
- We use Eclipse, and we use Java. The employed toolkit must have a Java API and be embeddable into Eclipse.
Selected Technologies and Rationale
Our rendering API of choice is Java2D. Rationale:
- Comprehensive rendering model with for Porter & Duff compositing
Here are some reasons for having our own 2D graphics framework:
- Need support for local and remote rendering
- ...
Basic functionality
Org.simantics.g2d and org.simantics.diagram together define a framework and structure for modelling diagrams consisting of an ordered set of elements. Diagrams are flat but elements can have hierarchy. Neither of these are used for direct rendering using Java2D, but they do define what will be rendered by defining how to form scene graph structures.
Org.simantics.scenegraph defines a way to form hierarchies of nodes that may perform rendering using Java2D. The scene graph nodes can also perform event processing and therefore support interaction. One way to define the scene graph is to say it shall unambiguously define what is to be shown on the output medium, i.e. screen, PDF or printer. In the Simantics Workbench, you can use the features of the org.simantics.scenegraph.ui plug-in to see what the scene graph looks like at any moment.
Diagrams and elements are loaded from back-end storage, i.e. the graph database. The storage back-end is listened for changes in the loaded diagram structure and elements. See Org.simantics.diagram#How_It_Works for how this process works. Currently GraphToDiagramSynchronizer is responsible for synchronizing back-end structures into diagrams and elements. Another important participant is ElementPainter, which is responsible for keeping the scene graph up-to-date with a diagram and its elements.
Primarily AWT input events are monitored and propagated to nodes by the scene graph. Events not consumed by the scene graph will be propagated to the G2D framework which will propagate unconsumed events to ICanvasParticipants as G2D specific events.
G2D and scene graph provide support for both desktop and remote (server-client) rendering through a network connection. G2D code is always executed server-side where as scene graph code can be executed on both sides. Its functionality is defined in more detail at org.simantics.scenegraph.
Plugins & Dependencies
- org.simantics.scenegraph
- A self-sufficient library for describing 2D/3D scene graphs, i.e. trees of nodes that can be rendered using Java2D/OpenGL.
- org.simantics.scenegraph.ui
- UI components on top of the scene graph library.
- org.simantics.g2d
- org.simantics.diagram
Dependencies
- cglib 2.2 (svn:2d/trunk/net.sf.cglib)
- org.objectweb.asm (3.2)
Releases
0.9.2 (in target platform 0.7)
- SVN - svn:2d/tags/0.9.2
- Repository - svn:2d/tags/0.9.2/repository
- New & Noteworthy
- Fixes
- Bounding box checking fixes, won't clip zero-area nodes away any more, such as horizontal/vertical lines (changes)
- Tooltip support for diagram elements through TooltipParticipant.
- Visual fixes for glitches in opening diagram editors.
0.9.1 (Shaky)
- SVN tag - svn:2d/tags/0.9.1
- Repository - svn:2d/tags/0.9.1/repository
- New & Noteworthy
- Rendering uses very primitive bounds checking to optimize what parts of the scene graph are processed/drawn. Due to the primitive nature of the implementation it is also really slow.
- NOTE: make your IG2DNode implementations implement getBoundsInLocal() as getBounds() previously or return
null
and make sure that your nodes do not override getBounds() to keep them working as before.
- NOTE: make your IG2DNode implementations implement getBoundsInLocal() as getBounds() previously or return
- Fixes
- ticket:612
- scene graph attribute dialog enhancements (r13480)
0.9.0 (Semi-stable)
- Ticket - ticket:610
- SVN tag - svn:2d/tags/0.9.0
- Repository - svn:2d/tags/0.9.0/repository
- New & Noteworthy
First release, getting into the release workflow.
Roadmap
0.9.4 (In Development)
- SVN - svn:2d/trunk
- New & Noteworthy
- Fixes
- Integrate Antti's diagram loading changes. Speeds up loading a lot and fixes caching issues in diagram graph requests. Removes unnecessary duplicate code element loading code and also speeds up the symbol library.
- Fixed big synchronization problems in diagram element loading & updating.
1.0RC1
- org.simantics.g2d#ASAP TODO
- org.simantics.scenegraph bounds checking optimization, current implementation is too naive. Possibly try caching transformed bounds.