jessyink-team team mailing list archive

[Marc Eberhard <eberhardma@xxxxxxxxxxxxxx>]

Dear Hannes!

On 15 November 2010 18:31, Hannes Hochreiner <hannes@xxxxxxxxxxxxxx> wrote:

> On 15/11/10 10:27, Marc Eberhard wrote:
>
>>
>> One possibility would be to implement the JessyInk functionality with
>> GWT and let the magic of Google's wisdom optimise the code for different
>> browsers. They have many good workarounds for different browsers built
>> into it. It's on my list of things to try, but I probably won't find
>> time for it too soon.
>>
>
> I just had a quick look at GWT (again). It seems to be a great tool, but I
> don't know whether it would solve the rendering issues. As I understand it,
> it optimises the


My experience with SVG in browsers is that rendering of a static SVG file
usually works OK, but when you start to change the SVG file dynamically you
find some browsers really run into trouble.

One thing GWT can do is to split the SVG into small static chunks. Instead
of one large SVG file to render, each slide is in its own SVG file and is
either displayed or not. That should make it easier for the browser. You
would do pretty much the same in the Java code as you do in the Javascript
code at the moment. You parse through the SVG file and collect the master
slide and other slides.

The difference is that in one case the browser loads the SVG file directly
and you need to manipulate this large file. For any change the browser needs
to rerender the whole file. That's what's making it so slow at the moment.
In the other case only a small HTML file is loaded and objects are added to
the page body as needed. The code to do that is highly optimised from the
GWT compiler and you only add the bits of the SVG file that need to be
rendered. That should make things faster and more robust. I suspect that
smaller SVG chunks will improve the browser rendering as there is less
chance for the browser to stumble over something.


> JavaScript code. Thereby, it eliminates some cross-browser
> incompatibilities and improves the performance of the code. At least the
> issues I was referring to, are problems of how different rendering engines
> display the SVG (whether or not there is a script embedded).
>

My feeling is that making the rendered SVG code simpler (no scripts in it,
just a short SVG block) will also improve the rendering. As far as I have
noticed, some browsers (Opera, Chrome, Safari) tend to cache some of the SVG
rendering. If you now manipulate the underlying SVG file they run into
problems. If however this SVG file is static and you only change the CSS
parameter of how it is rendered, these browsers should still do fine. The
same applies when you zoom into a page. The SVG stays the same, just the CSS
parameters of the widget embedding it change. So, the browser does not need
to rerender the SVG file itself and I think this difference will help. But I
could be completely wrong on this one. I'm only sure that it will be a lot
faster.


>
> This is not to say, that moving to GWT is not a good idea. One worry that I
> have is that GWT is very much geared towards "web-applications" in the sense
> that it is based on HTML and focuses on solving problems concerning form
> handling and server-client communication, which are not a big concern to
> JessyInk. However, if it


It depends on your point of view... GWT is a framework for writing web
applications. JessyInk is a web application in my opinion. It does run
completely inside the browser. Yes, GWT also offers communication
capabilities with a server, but that's just one tiny part of it. You can
save the GWT generated HTML/Javascript files on your local harddisk and open
it from there with your browser without the need for a webserver at all. If
you then pass the name of the SVG file you want to look at as a parameter,
you can pick that up in the GWT code and render the file. All without
communication and a webserver.

Have a look at https://code.google.com/p/lib-gwt-svg/ and
http://www.vectomatic.org/gwt/lib-gwt-svg-chess/lib-gwt-svg-chess.html for
an example of what can be done.
Closer to the JessyInk functionality is
http://www.vectomatic.org/gwt/vectomatic2/vectomatic2.html an example on how
to rescale/zoom/move SVG files with GWT.

For a good overview to show you the way GWT is heading, have a look at
http://www.youtube.com/watch?v=aW--Wlf9EFs if you haven't seen it before
(it's about 1 hour long).

improves the development speed and can be used with SVG I am all for it. Do
> you have some more insight into or experience with GWT?


It does improve the development speed dramatically as it comes with
extensive library support. Many things you have to code by hand at the
moment can simply be done with a library call, like keyboard handling, etc.
It's not the switch from JavaScript to Java that improves the development,
it's the huge amount of extra functionality already available through the
libraries.

I have written several GWT applications, like an attendance monitor and a
coursework server for my lectures. The more I use it, the more I get
fascinated by its possibilities. The only communication between my GWT
applications and the webserver is for implementing persistence. Everything
else runs on its own in the browser.


>
>
>> Even the JessyInk script could be in a separate file. That would make it
>> possible to upgrade to a new version of the script without having to
>> open all presentations in Inkscape again. What I wanted to try for some
>> time is to write a GWT application that would load the SVG file and
>> display it the same way as JessyInk does. The advantage would be that
>> the code can be written in Java and would be automatically optimised for
>> different browsers by the GWT compiler. You can also implement other
>> functionality easily, like mixing presentations, hiding some slides,
>> reordering them, etc.
>>
>
> Sounds interesting. If I understand it correctly, you would suggest an
> HTML-based page that loads one or more SVG-files. I can see some advantages
> to this method,


Yes, exactly. Something like:

www.myurl.org/GWT_SVG_Renderer?presentation=myJessyInkPresentationFile.svg

You have a base URL for the renderer and the presentation file is passed as
a parameter in the URL. Similar to the Vectomatic2 example above.


> but I wonder how the workflow would change and how Inkscape (or another
> editor) could be incorporated into such a set-up.
>

No change at all. You prepare the SVG file in exactly the same way. The only
difference is that GWT is reading the hints placed in the SVG file by the
JessyInk Inkscape extension instead of the Javascript contained in the SVG
file itself.

All the best,
Marc
________________________________________________________

email: m.a.eberhard@xxxxxxxxxxx, marc.eberhard@xxxxxxxxxxxxx
web:   http://www.aston.ac.uk/~eberhama/