 Thank you very much. Hello everyone. So a Gefi doesn't exist in the web world in JavaScript, right? But what if it existed in this different world? So we are. So let us present ourselves. So I'm Mathieu Giacomi. I'm the the original author of Gefi and I'm a researcher and Eduardo here is the lead developer of Gefi since quite recently and if you know Gefi a little he has been developing the data laboratory view right among other things and we've teamed up with JavaScript experts that know very well the the the web world for network visualizations Alexi Giacomi who is also my brother and Guillaume who is in the Guillaume pick who is in the in the room So they've helped us See what it would look like right see if you want so but I Need to talk about the context on why we are in this situation right now. So basically The multi-platform is moving from Java To web technologies right so the browser is now the new Multi-platform if you prefer and this is an effect from instance of So multiple factors, but one of them is the policies of Oracle, right? So they want Java to be more a back-end thing and less a front-end things So there are less and less user interface Features in Java. They are less maintained and we are kind of stuck in this general movement, right? And for instance a very technical real practical consequence for Gefi That's the the library the open GL library We currently use is not maintained anymore, right? And it will not be better in the future because of the general movement right of having less UI stuff in Java generally So at the same time the JavaScript is more powerful, right? We have crazy efficient applications now. It's more mature than what it was before We are switching from a web of documents to web of applications. So should we consider? moving Gefi from the Java world to the web world right in this talk that we will split in different parts We will see first how to fix Gefi and how to deal with these issues of deprecation of open GL libraries in Java currently and basically Eduardo redeveloped a new open GL engine for Gefi and then into the JS world What would we have to do to transition to JS? What it takes what it costs and what we would gain and Alexi will present that and Then we have a small benchmark that shows if JavaScript can really be as efficient as Java for graph visualizations and Without the further ado, I'm gonna pass the mic to Eduardo. Thank you so before talking about JavaScript, we will first stay in the Java world and I want to present you some problems that we found over the years with the the heart of Gefi, which is the rendering engine And there are a few problems first. It uses a deprecated open GL Functions very very old so they don't even work in some older or incomplete drivers and can crash many computers especially on Linux and OS X Also, it has a problem of a scale it cannot scale with the modern GPUs that you can buy nowadays because it has a lot of CPU overhead and that's because of calling a lot of functions of open GL on the CPU, which is just too much Too much calls every frame of the rendering and also We have listened to our users and they they want to use a Gefi rendering engine as a as a library they would like to have it on their own programs, but that's not possible at all because It's not modular and it's not clean and it's just not portable And also at the same time we are going to improve all of this we say We also want it to be Extensible with plugins so it's not just what it is but it can be changed by any developer And of course we can improve it so before creating a new engine. I found very few difficult choices to make mainly to one is to Java library for dealing with open GL in Java so get phishings Always has been using the geo gel library, but the problem with it is that is not maintained anymore We also want to thank the geo gel developers for the work during the years very awesome work, but Nowadays we have to Make the switch to another library And that's the likewise lightweight gaming Java library And it's great. It's great. It was very well It has many many functionality, but it has a small problem and it's that it doesn't officially support a Solution for building a graphic user interface which for Gefi as you saw before it is a deal breaker because We don't want to build a game. We want to build a desktop application or web the Integrates a graph, but the graph is not everything and also Last year we found that The future for open GL in Java or the desktop is a kind of uncertain that's because first bull can is the is supposed to be the successor of open GL, but still is unsupported by all their drivers of their GPUs or Or all their systems and at the same time Apple decided to deprecate open GL in 06 and They also said they want super bull can which makes them the only ones not doing it and It seems they are trying to infer metal, which is the their own graphics API, which is only for all sex and Ios But is that too bad, I don't think so Open GL still works in no sex. It will continue to work and Also, there are starting to appear solutions to fix this problem in the future So you can write open GL programs that work on top of metal. So It should become it should continue working for the future and also this Software being created in open GL nowadays So I don't think we should move that So now I will talk about the new engine that I have been developing To replace completely replace the the current engine of Gefi So you will see that it looks exactly the same but fixes a few known glitches or glitches It's also written from scratch only depending on the graph API the core graph So that should make it very very easy to integrate both in Gefi and other applications Also, it offers extension mechanism. So you can plug in some components to draw anything for example a background map or a Legend whatever and you can also extend the the input so you can write Plugins to deal with the user in user interaction for example And also I wanted to make it work with all their All their versions of open GL which some older machines Might support but no the new the new shiny things of open GL for for example so this engine Tries to use what whichever functionality is available going for from best to to older Which affects performance bad? If the new version of open GL is available, it should work really fast and much better than than nowadays and the other aspect of designing this new engine is that is It changes from the fixed pipeline of open GL to this shader based modern open GL which makes it easier to to write some plugins to render anything and also it tries to be high performance by using the following the Approaching zero driver overhead design principles, which in summary means that you do All the data preparation work on the CPU in a buffer in a low-level buffer You don't call open GL functions at all and when you have all the data already you call the Open GL function once to tell it to draw everything in a single batch or two batches or whatever so that makes it get the use correctly the powerful GPUs that nobody are available And also the geometry of nodes and edges Before it was being repeated and sent again and again now we have one instance of the node geometry and we Transform it on the shader. So that saves memory for the graphics card and that saves That interchanged And about the previous problem that I talked about geogl or the lightweight Java gaming library I think the correct choice is this one first because It's maintained nowadays. It also offers Vulkan support. So in the future if we need it we Just can use it But the IWT problem. Why what can we do to build a user interface? well There is one small project in github and official that offers that it works quite well only for Windows and Linux at the moment, but We would like to Implement it for OS X2 and make it better and contribute that Let's do a small demo Okay, so we close Gefi with the same graph and we are using the the new engine We are using it with a very Simple card, which is the integrated Intel card It works much better if you if you use a powerful card, but as you can see this is a this is a window That is completely out of Gefi. So you can you can Use it in your own programs. It's also tested on different drivers. For example Gefi currently crashes on my linux Installation, but this engine doesn't crash and will work fine and this is a smaller graph, but We have seen it work with millions and millions of edges Which is not possible with current Gefi and Matthew will tell us about that later. So now Thank you So know that we've seen the whole part about how fixing Gefi in the Java world I'm going to try to Explore what it could make possible or impossible to write Gefi for the web first, I think the most important thing is to Describe what I think is challenging is in writing Gefi I've been using it Years ago and I think there's two free main qualities of Gefi The first thing is that it must be able to render hundreds of thousands of items or millions of items Really smoothly like as often as possible if possible like 30 times per second Without freezing the whole computer or even just software itself Also, it needs to have a Performance graph model. We need to be able to at the same time that we're drawing this whole graph 30 times per second compute like Community detection algorithms or ranking algorithms all of this still smoothly and without Freezing the whole computer or the software itself And finally one of the main qualities of the of Gefi is its plug-in capabilities You have to be able if for your needs your business needs to implement a specific ranking algorithm or something To integrate it inside Gefi without having to rebuild the whole thing Also, the solos like the current marketplace of Gefi you can download a lot of different features That make Gefi around Gefi and that makes it solve your business needs So those two those three things are I think the three main challenges About web development there is some obvious trade-off when you come from the Java world going to the JavaScript world. Let's see like this first The most web technologies have been mainly designed for Writing interfaces. So this whole block management styling forms inputs. This is so easy in the web this is Made for it. I don't know exactly how it is in Java, but I think it's okay Thank you and also if we successfully bring Jeffy to the web we will still have it work in every OS and Also on mobiles. I don't see that asian is working on Gefi on mobile right now, but This is quite imaginable, but tablets. I can imagine a lot of people want to work with Jeffy on tablets and Minority report effect to move the graph with your fingers things like this This will become possible if we move to the web and without any effort But at the same time those big losses that we will meet instantly Memory kind of doesn't exist in JavaScript. We never know how much memory we are using We do not know how much memory we can use and this boundary is actually unpredictable. It depends of The user's computer his browser if the browser has all the tabs open, etc So we know at some point it might crash and make the whole thing stop working, but we never know when this is quite uncomfortable to work with Also, we do not have multi-threading in the web. I Speak about it later, but we do not have very much usable multi-threading and finally One minor point that is not written here I will not speak about canvas and edgy etc because this is all CPU based and this doesn't scale So we will already accept that if Jeffy moves to the web it's going to be with WebGL But WebGL which is our best solution is just a subset of OpenGL It's based on the OpenGL yes specification that is a portable OpenGL And it lacks some features of it and other features are actually badly implemented so That's Something we will have to work with So let's talk about web performances I think One way to synthesize all the research is an improvement that have been brought to this community in the last few years There's a lot of people who've been working to make the web more Perfomant by improving the JavaScript engines themselves and I think the most famous success of this part of of This field is V8 from Chrome. It's maybe one of if not the best interpreted Interpreted language engine that we have now you can write JavaScript like Without caring about performances and V8 will make it like Perfect, that's very very nice and on the other hand those people who are trying to make the web a Perfomant platform to allow people to actually run byte code in it So you will develop low-level applications with C++ or REST and compile it and put it in a browser and The browser becomes kind of a new JVM or something that will make people able to just run fast code in it But it's no more JavaScript so the JavaScript part let's say it's all the web development that is modern now like react application Angular all those frameworks and ECMA 6 ECMA 7 the new debugging tools All this part that is what I think is web development today It's really great because as I said you can just write any kind of JavaScript and it will be fast But we have kind of a specific use case here Writing thousands of DOM nodes and having run smoothly is something Drawing millions of items is really different. So I think All this web development ecosystem doesn't actually solve all our issues and on the other hand Writing low-level code and running it in the browser as a as if it was a virtual machine only Is not webby. I'm a web developer and I want to keep beneficiate from all those nice things the debuggers The the new specifications of the live scripts that are brought every year, etc So what I don't like in this part is that it's no more web development We were writing in the slides No, not in the web culture so many times that we just created a label for it. That's gonna make it easier to identify So to wrap up this part we don't have the same needs as classic web apps WebGL is the best we have and we want if we move to the web To create some things that is webby we want to beneficiate from all those nice things that are that have been brought in web development this last few years no Liam and I have been developing Sigma J s for some years and we have some feedbacks about what is doable and what is hard and Yeah, about writing a web web-based graph visualization library So first let's speak about a bit about webgl For a web developer working with webgl means working with low-level data structures Which is not very in the web culture to say quickly you work with byte arrays That's nice, but you don't have you don't have the API is to actually do what you want You cannot allocate or unallocate memory as you want because this is not JavaScript This is not what JavaScript does and so this is kind of painful to work with a jail for a web developer also Rendering efficiently custom shapes is hard. I mean The first time I started working with a jail I spent more than a week to just draw a plain disk and another week to draw a plain disk in front of another disk That was kind of awful and it requires lots of tweaks and every side and The home has been working just to draw curves efficiently and he could speak two hours about it and This is quite painful Also, it is not 100% stable if you work with a jail you have to accept that at some point It will break and stop working and you will not find out why and also you will see a lot of weird artifacts really a lot of them Okay But it's the best we have about the graph model we have kind of a dilemma here because working with Efficient dynamic JavaScript structures such as objects and arrays etc. Is really nice because the APIs are nice And it's all fast because V8 is awesome, but it takes a lot of space in rum It takes so much space in rum that we expect that at some point we might cross this imaginary boundaries that we cannot identify so This is not our Solution we cannot base our old rough model on these Data structures with all the indices we want because at some point this is gonna be the issue and at the same time We could work with by the rest, but It's not in the webculture state There's a lot of things that are very hard to do and the code will be hard to maintain and hard to test so We think the best solution would be to have a hybrid solution, but still this is be this is gonna be something challenging Finally, I want to speak a bit about threading so We have no multi-threading in JavaScript, but this is how it works You open a web page and you have one thread that will be shared between the JavaScript engine So as long as you have JavaScript training nothing else runs in the thread and the rendering engine So this is called the event loop if you have a synchronous task running into the main thread The event loop will be blocked and you won't be able to scroll the page or hover simple buttons elements of this kind of things But first of all if we stop If we stop working with canvas and SVG or DOM and we start working with WebGL the rendering will not Free the event loop. This is kind of the good thing even if the GPU takes time to render the image The event loop will still be properly running and Finally, we have web workers that allow us to actually run heavy computations aside from the main thread so without blocking the event loop But you have to share your data and actually transfer it So as long as the web worker is running is working with your low-level structures, you cannot access it anymore from the JavaScript main thread, which is very real. It's like all your references are broken and you cannot do anything So you cannot render it anymore We know that there's a new API that's named offline canvas API that might allow us to actually Trigger rendering from the web worker So we might have actually the whole rendering and computation engine working on a web worker and keep the event loop running smoothly and safe so It's actually not that bad. We might be able to do something working nice So how to actually move Jeffy to the web? We do think there's two main solutions The first one would be to actually recreate everything in JavaScript with all those modern tools, etc We already have graphologies that have been presented here by Guillaume one or two years ago So it's a graph model, but it's mainly an API so you can reimplement it while benefiting While benefiting from all the plugins that have been already in developed so algorithms implementation mainly Sigma's rendering engine in the new version that Guillaume's been working on is becoming faster and faster So we already have some code. We might actually Wrap it up and create something that works and also it's working on the web With the web development spirit and tools. So this is something that I quite like we could also go to the developing everything in surplus plus or rust and compile it to bytecode and having a faster in software but This won't be a black box because we need actually APIs that will be able to communicate with JavaScript and I think that's the main issue with this solution Having a low-level code that will open APIs that will work with simple JavaScript without having to Work only with low-level structures. I mean in for plugins developers Could be painful and I think it's better to actually not do this without this plug-in constraints I think the black box would have been something acceptable, but quite not So our recommendation finally would be to actually embrace web culture and if we want to develop Jeffy for the web not trying to do the brother as a virtual machine thing but more Developing something with JavaScript and all those tools We have more solutions that we expected Starting working with this talk. We actually didn't expect to say this at the end Especially you'll see the benchmarks, but the situation is not that bad for the website implementation without having actually Try to do anything special for this talk and I think Developing Jeffy for the web is something that would be totally possible. We have to rethink it With the capabilities of the web and then we might be able to solve the actual same problems, which is our goal That's nice. Thanks. So let's talk about The speed right on the web world. So we've done a benchmark Right, so I'm gonna show a few charts and they have the frames per second on the y-axis and Pay attention that is log scales. So Right, it goes 10 101 Thousand frames per second right and so here we test on different networks Three engines the current Gefi engine in open gel in orange in blue in the middle We have the the new open gel engine that has just been presented by Eduardo and in gray We have the web gel engine In JavaScript. So basically it's a Sigma. We just did not try to display the labels in this benchmark And it has been done on this same computer, which is a kind of researchers computer and These benchmarks have been done with the Nvidia chip But it's not a it's not the powerhouse right and the resolution is like 2000 and a few hundreds by one hundred one thousand and four hundred so quite a big resolution And as you can see on these big networks Let's talk about the size of just the end after the end you have the number of nodes and after the e You have the number of ages so that this one the Marvel superheroes network has 10,000 nodes and 100 almost 200,000 edges and it's rendered quite comfortably with the new engines above 50 frames per second and what you can see is that The JavaScript is already quite largely overperforming existing Gefi, right? so sigma j s on the full-screen resolution is much better and the new open gel engine is also a even little better and The new open gel engine allows to display huge graphs that we are not currently able to visualize in Gefi Right, so like the Google graph this one has a 800,000 nodes and five million edges so We have different options for the open gel the new open gel engine So we have joggle and LWJ GL The two libraries and we have different options in terms of when do you swap the buffers? Do you wait for the full rendering? How do you give more reactivity to the users by allowing the buffers to swap at any moment? Whatever these things? Produce kind of the same Range of performance, so they don't matter so much for our performance. We can pick whatever is good For us in terms of design and user experience. So it's just good to know And now let's talk about scalability so here It's different networks that have an increasingly large amount of nodes So an order of magnitude each time up to 10 million nodes. They have this network has no edge and So first of all you see that we have this kind of plateau in the beginning This is just due to the fact that you have a cap in the number of frames per second We don't see us human more than maybe 100 frames per second So whether you cap it at 30 or 60 or whatever actually all these engines could could go much beyond We just don't do it because it's useless. So the plateau here is not really representative But then it starts to drop and it starts to drop Because there are too many nodes for the GPU basically or the CPU depending and what you can see first is that all of them start to drop at kind of the same moment right between 10,000 and 100,000 nodes and Then so they don't drop necessarily at the same rate but you can see that for instance the The we can reach 10 million nodes with the new open GL engine also we couldn't load Such huge networks with the web GL engine That's why I must talk a little bit about that because you've seen a lot The issues that arise with web technologies. So here the file was too big and We can actually find the turnaround to be able to load it So we didn't take the time to develop that in addition to do this big benchmark with we didn't have the time but basically web technologies Are not used to load huge file and that's why it's break. So solutions exist So we could we will be able we would be able to find turnarounds to use to load huge files But currently it's kind of not available because that's not in the practices of these people So we don't have the figures So let's look at the edges now that we have seen for the notes and basically it's kind of the same picture So it drops at the same point. So it means first that in terms of Scale ability one node on one edge are kind of worth the same Right, so you could estimate the size of your network in terms of nodes plus edges, right and it gives you How you how far you would go so basically to have an idea things are Usable with your in your Interactions with your with the software above 10 frames per second or around 10 frames per second on Above below that it becomes so laggy That you cannot really interact with the network. It's kind it works kind of a Static thing right and you can see that we can almost go to one million edges With the new open-gill engine and we could also Achieve quite decent performances with the webgm We also tried so though it looks like a stupid idea to to see what what it looks like if we have Networks with a huge amount of metadata Let's say nodes have many many many attributes like full-text stuff or whatever Well, it shouldn't change the rendering right and that's it doesn't change the rendering for the open-gill engine But it turns out that it actually takes a toll on the on the performance of the webgl Engine even though the metadata doesn't matter to the rendering and the reason is the crazy magic optimizations done by V8 Are different with objects that have a lot of keys and a lot of stuff So it makes different optimizations and then the performance drops so this would mean also We would require this would lead us to develop a hybrid engine where we would Split the rendering part and the metadata part for instance or such strategies and Let's talk about the screen resolution on the left you have on different Networks the frames per second on a small screen and on the right on the huge screen that screen and it's actually quite flat It means that it depends much much more on the size of your network Than the size of your screen and this is quite specific to open gel webgl. I think canvas is not the same So it means that we could have a much bigger screens even on small chips It will still work and that's a really great news Including for the webgl. So this is just the open gel, but it's also the came the case for a webgl and let's look at the influence of a GPU right if you use a huge graphic card, so we've tried with the on the right the g-force GTX 970 which scores like eight thousand on G 3d mark while the left one scores only one thousand and three hundred and basically webgl in Yellow and the new opponent gel engine in red Gain performance, but current Giffy engine doesn't so it seems to go down But actually it's like one or two frames per second basically you just you should just consider it's kind of the same But the thing is we have a CPU overhead which caps the gain we have with a future GPU so we would gain more performance in the future So let me wrap up that very quickly If you're a developer the ticks away the takeaways here are that web technologies We think are the new multi-platform for graph visualization Webgl allows you to visualize 10 to 100,000 of node splurges on your browser today With a normal computer with no special graphic card, so this is great news But the challenges are different I will not dig into that again, but you've seen that and We just have a few things to know if we go that way, which is that the libraries are not mature for data science So we have to develop stuff in JavaScript that is more compliant with data science practices and this will come and These practices are not in the web culture as you've seen and also for plugins development and stuff like that the researchers Or the users would have to learn a new culture that is different from the Java world And if you are a Gefi user know that we will transition from a software to a project with maybe different tools And that the web will be part of the future of Gefi, but this doesn't mean that we will drop the Java Gefi and especially not in the moment, but if things go even Worse with Oracle and stuff like that and they really want to I don't know for instance completely stop the open GL supporter Whatever I know we have a fallback, which will be the web technologies But right now we don't plan to drop Java and this might finally lead us to get a decent user experience for Gefi Thank you very much for your attention in JavaScript Okay, so that's the that's the running of the force at last impact the performances for the rendering and I think that Considering that the rendering is almost only on the GPU in the ideal world Which means with the new engine and the force at last is only on the CPU So it we wouldn't lose too much of the performance, right? Yeah So do we plan to use clustering algorithms to only show the edges that are relevant to the analysis and not all of them because it's too much and The answer I mean I will want to Say Joker here. So this is a methodological question. There is no problem for implementing these such algorithms, right? But because we are so few of us we focus more on the Basics of Gefi like the core engine and stuff like that and this can be done as a plug-in and like for instance The Leiden algorithm that is a kind of another version of the Louvain algorithm for modularity clustering The guys who published the paper with the help of Eduardo just published a plug-in for Gefi And this is the right path So if these things comes we will we will create the plug-ins host them and might we might even include them in Gefi And the same applies to the Java script world where graphology is an engine That can host this kind of algorithms and it's also possible to make a pull request in that direction Another question maybe Did we consider webGL frameworks like 3js? Maybe this is a question for you Yes at the beginning we thought about it, but the thing is it brings us Far from the metal as Guillaume says so basically it brings like a one megabyte Java script just to draw disks and lines Which seems overkill we prefer to go trying to actually work with WebGL directly especially since we have only 2d needs and there's no except for pixie.js Which is actually something we can't think about the most webGL engines are more 3d oriented Which one? Regal, okay. I'll take a look at it. Are we Quick Not only So this is an excellent question I would just say that doing this kind of stuff is a UX issue So we will be able to address these kind of issues in the web world and not in the Java world because it's so costly right now To develop advanced UX stuff in Java It is something interesting. I think we already have a few initiatives in that thing. We can discuss about that later Thank you very much