Hi Vincent, > There are ways to export the SVG rendering as a set of Java 2D primitive > calls. However, depending on what you want to achieve (e.g., do you > want to retain filters as filters?), the size of the code you will > need to send to a client will vary....
Filter can be generated as kernel for transformation matrix that will apply to the rendering sheme ;-) I still think that most (i do think *all*, but say *most* because i need to have a deeper analyze here) of the SVG spec can be translated to a Java2D bunch of methods and code ! The referencing of the potentila dynamic nodes (noted as "id" valid) can be referenced as DOM nodes pointing to a meta Method: internal class strucure may be subset with several methods that could be called in diffenrents ways according to the potential use of modules ... (this is just an example of ideas to prove that solutions exists for each problems here) > Getting this to work for SMIL and scripting is not trivial at > all, if possible. Scripting on SVG is not so hard IMHO, but i aggree that scripting on SMIL will be much more complex to translate as valid java code mainly due to the difficulties regards the media synchronization :( But why not start just with SVG first .... > Anyway, I think that some investigation into converting an SVG > document in a Java class could fit under our transcoder umbrella. That was also the purpose of my post ... > Vincent Hardy. > > Jean-Baptiste Bugeaud wrote: > > > > Hi, > > the more i look at SVG the more i think to myself : Why not replace > > Flash with SVG ? > > > > Let me continue : What is missing at this time in Batik SVG that Flash > > has now to offer (on the animation and graphics ground) ? > > For me the answer is clearly : SPEED ! > > > > I've think for long time on how such a speed can be acheive : > > Why not move most of the lauch time jobs to an dev-time job > > (including stream-getting+parsing+rendering)? > > > > Here is how : > > You've got a SVG file that you desire to speed up its display : > > using the Batik SVG DOM parser you create in memory > > then a renderer (the thing that must be build) browse the DOM and > > generate a Java source file that exactly represents the SVG file using > > a buch of Java2D primitives (in a class inherited from JComponent. > > > > Then you compile the .java to a .class ! > > > > Next step is to use the .class as a valid JavaBean in a program as a > > cosmetic stuff or include it directly in an JApplet to make ala Flash > > file (a generation option may directly generate a JApplet instead of a > > JComponent) ! > > The difference of such a technology is that only few files are > > deployed (just the generated .class) and not several MB (no need to > > deploy the batik framework)! > > > > To achieve such a goal, you may start with the upcoming J2SE1.4 spec > > so you will get powerfull Java2 pipeline (pretty impressive speed) and > > JAXP API (to store dynamic nodes that need to have properties exported > > to be impacted by potential events such as mouse moce or click). > > > > Such a technics may be applied to the SMIL+SVG spec to have a complete > > Flash replacement solution (using JavaSound also include in J2SE1.4 > > and JMF) > > > > Do you think such a renderer may be interesting for the Batik project > > ? -- Jean-Baptiste Bugeaud www.up2go.net - The JNLP Repository :o) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
