>>>>> "JB" == Jean-Baptiste Bugeaud <[EMAIL PROTECTED]> writes:
JB> 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....
JB> Filter can be generated as kernel for transformation matrix that will apply
JB> to the rendering sheme ;-)
I'm not sure if you understand what a filter is in SVG. There is
a set of ~13 predefined filter effects in the SVG specification
(Chapter 15). These range from the rather straight forward, lookup
table, color matrix, and convolution operations, to 3D lighting
effects, noise generators and morphology operations. Clearly these
filters (or references to them) could also be packaged up in the SVG
description but the result will be much larger than a paint method
with a bunch of fill/stroke calls.
I'll also point out things like gradient fills (linear and
radial), pattern fills (doing this efficiently requires significant
support).
JB> I still think that most (i do think *all*, but say *most* because
JB> i need to have a deeper analyze here) of the SVG spec can be
JB> translated to a Java2D bunch of methods and code !
Clearly all of it can be, it's just a matter of compactness.
JB> The referencing of the potentila dynamic nodes (noted as "id"
JB> valid) can be referenced as DOM nodes pointing to a meta Method:
JB> internal class strucure may be subset with several methods that
JB> could be called in diffenrents ways according to the potential use
JB> of modules ... (this is just an example of ideas to prove that
JB> solutions exists for each problems here)
>> Getting this to work for SMIL and scripting is not trivial at
>> all, if possible.
JB> Scripting on SVG is not so hard IMHO, but i aggree that scripting on SMIL
JB> will be much more complex to translate as valid java code mainly due to the
JB> difficulties regards the media synchronization :(
Well, given that Java-Script can create and evaluate new code on the
fly doing this requires a Java-Script interpreter on the destination.
JB> But why not start just with SVG first ....
Certainly, actually looking at one of the new mobile profiles
would also probably buy you a lot in terms of picking a reasonable
subset as well as pointing towards a good staged implementation...
>> Anyway, I think that some investigation into converting an SVG
>> document in a Java class could fit under our transcoder umbrella.
JB> 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
>> > ?
JB> --
JB> Jean-Baptiste Bugeaud
JB> www.up2go.net - The JNLP Repository :o)
JB> ---------------------------------------------------------------------
JB> To unsubscribe, e-mail: [EMAIL PROTECTED]
JB> For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
