jessyink-team team mailing list archive

[Hannes Hochreiner <hannes@xxxxxxxxxxxxxx>]

Hi Marc:

Sorry for the delay in the response. I spent some more time looking at 
GWT, although I have not yet had time to watch all the videos on it. 
Continuing our discussion:

>     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.

Do you have some examples for particular changes that seem to cause 
trouble (e.g. example files or links to documentation)? I have not yet 
come across these problems, but I would be really interested. So far, 
there is not much browser specific code in JessyInk, but if the browsers 
have specific problems with the modifications done by JessyInk we should 
try and put in the required provisions for each browser (e.g. by 
transitioning to GWT).

> 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.

I think there are different aspects we should consider:

*) Changing only CSS parameters also occurred to me at some point. The 
problem is that not everything JessyInk does can be achieved using CSS. 
For example, last time I checked it was not possible to change the 
viewport using CSS. Since this is a very popular feature, I think we 
should try an conserve it.

*) Yesterday, I did some tests with large bitmaps to see whether they 
had an impact on rendering when they were kept from rendering using 
display: none. My impression was that there was only an impact on the 
rendering speed (and therefore the framerate), when they were visible. 
But I will try and put some numbers to that. I also did a quick search 
for documentation on this topic (how rendering is handled and how much 
impact invisible objects have), but I have yet to find something useful. 
My suspicion is that objects that are not visible (display: none) only 
cause very little overhead. In this case the partitioning would not 
yield that big a speed improvement.

*) On Ubuntu 10.10 using Chromium I get considerably better performance 
than using Firefox. Also, Firefox on Windows seemed to perform better 
than on Ubuntu (using comparable boxes). So I guess part of the problem 
is down to the implementation of the rendering engine. However, since we 
can't really change that, I guess we can skip this point.

In conclusion, I think it would be good to have some examples, 
documentation and/or numbers for the most common use-cases to judge how 
big an improvement we get from partitioning the file.

>     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
> <http://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.

Let me see, if I get this:

Essentially, you would then have an HTML(?)-page created using GWT 
containing the JavaScript code (either directly or linked) and an SVG 
file prepared in Inkscape (or any other editor) containing some 
annotations. I can see how this works, if you can put things on a 
web-server, but could you also still use the presentation locally? Would 
the HTML5 APIs for local file access help?

I guess there are a some features that I would like to see in JessyInk 
and that I am not sure we can get/maintain in moving to GWT:

*) The files are self-contained. Although this is a feature I value, I 
would not rank this a "must have".

*) The files can be used locally (edited and viewed) without an Internet 
connection or server running.

*) JessyInk should be modular and it should be possible for people to 
write extensions for it. (I just finished an alpha for version two, 
which is very modular and will allow people to add features by simply 
copying elements. I'll release it in the next days so you can have a 
look at it.)

Well, thanks a lot for your input. I really appreciate it. I think there 
are exciting opportunities for the future development of JessyInk, but 
since there are many ways this project could take it is important to 
have a thorough discussion about which road to choose.

Happy holidays,
Hannes