Drawing SVG in the Cloud
CC Attribution - NoDerivatives 2.0 UK: England & Wales:
You are free to use, copy, distribute and transmit the work or content in unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Girow, Andrew
Google Application Engine is a cloud-computing infrastructure for creating and running web applications. Google Application Engine does not allow all Java classes to be used, For example, no graphics classes are allowed. At the same time, there is a need for the server side graphics on Google App Engine. TinyLine fills the gap and brings in the vector graphics to Google App Engine. We discuss some technical basic behind TinyLine and Google App Engine and show how Google App Engine Java developers could use and benefit from TinyLine. We go from the simple to more complex examples, starting the basic 2D drawing capabilities demos and SVG thumbnail images service. Then we show that thumbnail images are convenient way to present SVG previews to users. The thumbnail images could be used for the SVG listings, SVG directories or for SVG result lists of search engines.
 Thank you for coming. It was nice presentation. It was about Java and Java 2D and swing. And I'm going to talk about it. Also Java development, but there is no Java 2D, no swing. But still we want to draw something like vector graphics and SVG of course. Sometime ago, I think 2009, Google came up with the Google application engine. And out of curiosity I just looked at what Java developer can do with it. And I found out from the talk bags on the Google groups and the SVG developers, I just noticed that the Google application engine lacks of drawing capabilities at all. And there are a lot of requests for Google and for community what to do about it. Still people want to draw something even on the cloud computer environment. And I just see the opportunity to put a tiny line to run on the Google application engine to see what can be done with this combination. So we will talk about a little bit technical basics. Google application engine, also technical basics tiny line. We'll see some demos and a couple of words about basic development and answer some questions. Google application engine, as I said, it's cloud computing technology which allows us to run scalable Java web application using Google infrastructure. It has Java runtime and provides some start of API for the data store and some services. What is important for us, it supports Java runtime environment number six. It has some Java service and Java service pages API. It provides Java data object and persistent API for the data store and has some common tools in the development environment. Data services, because it's cloud environment, you don't have access to the file system. So it should store somewhere database in your data. They provide several levels of storage, like memory cache. They have data store, like a big flat database distributed over the data centers of the Google. Also they have service for fetching different resources from the internet. They have mail service, which allows you to send some images to your client. Image services and some scheduling capabilities. Because it's cloud environment, the scalability is very important. The scalability provided that they put some restriction or the JVM running because they want to route different request to different data centers and different web servers distributed globally. So the sandbox introduced by Google doesn't allow to build new threads, to have some direct network connection to outside, to write directly on the file system. And I also surprised, they don't have support for Java 2D at all. And you don't have an opportunity to run native code through the GNI. So there are some alternatives on the right side of the table, so you can Java developers can use to overcome the restriction. And one of them I liked a lot of software rendering, this is exactly what the TinyLine does. As I mentioned before, there is a need for server-side graphics even in a cloud computing environment. So the people want to draw something on the server-side because they collect data from other data centers. And as we heard before, for example, on the OpenStreetMap, there is still a big issue for drawing tiles on the server-side. Drawing tiles is a pretty expensive business, so it's CPU-consumptive. And the general approach to have several different services running through to render the vector graphics into the bitmaps. It's about the need at the same time as support of the Google application agent, provide very limited support for the graphics. So they have some sort of API that allows you to upload a big image and scale it down, for example, or run some filtering on it. But that's all. And the way to overcome software rendering. So a couple of words about the TinyLine. It has two basic elements, the 2D graphics, which basically the core technology of the TinyLine provides some basic tools. Basic path rendering and besorker rendering, text rendering, other color, solid colors, bitmap colors, provides the field and stroke and datum operation, all basic stuff you need to expect for the 2D library. Of course, it provides anti-alaska in opacity and left and right text layout. A couple of words about drawing pipeline. It's pretty straightforward. So I think if you're interested in it, you can look at it later on. It's not very complicated. 2D library supports painter models when you all concessive operation paint one over another. It supports different coordinate spaces like user space, text space, device space, pretty similar to the PDF model. It supports, of course, text fonts and colors. A TinyLine SVG build on top of 2D library and supports basically SVG Tiny11 plus engine, which includes SVG fonts, different raster images, text elements, smile animation and events. It has very easy to use API. Similar pipeline, which includes the 2D pipeline. It's just generally show the flow from the text input to SVG input stream, going through the build SVG document and then resurrect the 2D pipeline. It was very easy to make TinyLine run on the Google application engine because TinyLine doesn't use AWT or Java 2D for rendering. So it's no classes to depend on and no peers or whatever connection to the hardware. So it was ported very pretty fast. So this was missing, which is missed also in the Google application engine and how you can import the PNG graphics, for example, or GPAC graphics into a Java environment of the Google application engine, or you can write or export PNG graphics. All these drivers on the standard Java environment, they're written on native code. They are part of AWT. This part was missing and implemented pretty fast. And 2D and SVG canvases were implemented to run in the Google application environment. And this is a list of these classes. Now they talk about basic demos. First, it comes to the two sets of the examples. The two examples show the basic drawing operations, so we can basically switch to the real web application, running on the Google application engine. Wow. I can't see too much. For example, this drawing of the reserve curve. I can see it. It's coming. And here's drawing of the different gradients. Also coming this image in the middle. It's generated on the Google application engine exported to PNG. The whole list of these examples have pretty much every feature of the 2D engine, so you can check it out. The next example is SVG drawing service, so you can upload your SVG file or make a link to SVG resource and have PNG images generated on the fly. So this example, for example, the image generated three different sizes. Also, you can play online. This, for example, we can draw 400. It's too much. Let's draw it. And 200. And here they've gotten the PNG generated on the Google application engine infrastructure. And the side effect of the tiny line running on the Google application engine allows other applications that are using SVG to run on the same Google application engine. For example, I took barcode application and made a driver that draws the barcode using tiny line infrastructure. And as well, generate barcode using Google application infrastructure. For example, generate barcode like that. These are the basic examples for using tiny line on the Google application engine. More advanced example came up when I heard the... Sorry. Next one is about storing and searching SVG files using Google application engine. The idea was just to evaluate technology to upload the SVG files into the Google application database and try to search them and to use tiny line as a tab nail services which allows to evaluate technology for drawing a lot of... directory of SVG files using tab nail images and to present directors of SVG like type nail images and the result of the search as a list of the tab nail images. And basically it's better to see that. So the real application. So what you see is a list of tab nail images and all images sitting on the database of Google application engine. So user can upload the new images. He can provide some description or caption for it. You can edit it or download or delete it. Also you can search this database, so called database because it is more for example for... for keywords. And you get some subset or result of the search that has SVG because SVG presented as text, as XML text. So with one year when the user upload the SVG file into the database, SVG arch application just grab all the text nodes from the SVG, make some stamina on it and store the search, they call the search map into the database. And later you can pretty fast find out the images for the keywords. So basically now I talk about limitation because I have maybe 5 minutes, right? A bit more. Basically limitation of the approach presented because the Google application engine has some limit of the size of the entry. You can put in a big database like 1 megabyte but it's enough for a lot of SVG images. It's reasonable size, it's enough. And if it's not, it could be changed. You can use several entries for one file. And number of searching terms, it's limited to around 5 because we use the basic full search approach, not full blown library. And in the reading part it supports SVG tiny 1.1 plus which is limitations not like SVG 1.1 full. And natural future development could be support of the SVG tiny 1.2 and SVG 1.1. Oops. Okay. Just lost the visual. Okay, never mind. Nothing actually to show. And development of the search robot which can crawl the Internet and store the SVG images into the database. Now ready for questions. Thank you. Thank you. We have a 5 minute for questions. I have a couple of questions for you. Why did you use Google App Engine M.0 S3 from Amazon for example? First it's because it's written in Java and it was very easy to jump in. It's a lot of easy. I investigate the Amazon EC engine and find it more difficult. And now the question. The second question is why did you target a so small part of SVG and what was your goal at the beginning to embrace the biggest subset? This limitation of the tiny line library because it's currently support just SVG tiny 1.1. And it was historically limited to the size because the target, the previous target was mobile devices and it's going for the mobile devices. Actually I was thinking to use Bateek as a front end and the tiny line as a back end like render for Bateek doing all the preprocessing like CSS and SVG 1.1 support. But actually drawing to be done using tiny line. And this way I can make it bigger. Okay, so thank you very much. Thank you.
 Thank you for coming.  It was nice presentation. It was about Java and Java 2D and swing.  And I'm going to talk about it. Also Java development, but there is no Java 2D, no swing.  But still we want to draw something like vector graphics and SVG of course.  Sometime ago, I think 2009, Google came up with the Google application engine.  And out of curiosity I just looked at what Java developer can do with it.  And I found out from the talk bags on the Google groups and the SVG developers,  I just noticed that the Google application engine lacks of drawing capabilities at all.  And there are a lot of requests for Google and for community what to do about it.  Still people want to draw something even on the cloud computer environment.  And I just see the opportunity to put a tiny line to run on the Google application engine  to see what can be done with this combination.  So we will talk about a little bit technical basics.  Google application engine, also technical basics tiny line.  We'll see some demos and a couple of words about basic development and answer some questions.  Google application engine, as I said, it's cloud computing technology  which allows us to run scalable Java web application using Google infrastructure.  It has Java runtime and provides some start of API for the data store and some services.  What is important for us, it supports Java runtime environment number six.  It has some Java service and Java service pages API.  It provides Java data object and persistent API for the data store  and has some common tools in the development environment.  Data services, because it's cloud environment, you don't have access to the file system.  So it should store somewhere database in your data.  They provide several levels of storage, like memory cache.  They have data store, like a big flat database distributed over the data centers of the Google.  Also they have service for fetching different resources from the internet.  They have mail service, which allows you to send some images to your client.  Image services and some scheduling capabilities.  Because it's cloud environment, the scalability is very important.  The scalability provided that they put some restriction or the JVM running  because they want to route different request to different data centers and different web servers distributed globally.  So the sandbox introduced by Google doesn't allow to build new threads,  to have some direct network connection to outside, to write directly on the file system.  And I also surprised, they don't have support for Java 2D at all.  And you don't have an opportunity to run native code through the GNI.  So there are some alternatives on the right side of the table,  so you can Java developers can use to overcome the restriction.  And one of them I liked a lot of software rendering, this is exactly what the TinyLine does.  As I mentioned before, there is a need for server-side graphics even in a cloud computing environment.  So the people want to draw something on the server-side because they collect data from other data centers.  And as we heard before, for example, on the OpenStreetMap, there is still a big issue for drawing tiles on the server-side.  Drawing tiles is a pretty expensive business, so it's CPU-consumptive.  And the general approach to have several different services running through to render the vector graphics into the bitmaps.  It's about the need at the same time as support of the Google application agent, provide very limited support for the graphics.  So they have some sort of API that allows you to upload a big image and scale it down, for example, or run some filtering on it.  But that's all.  And the way to overcome software rendering.  So a couple of words about the TinyLine.  It has two basic elements, the 2D graphics, which basically the core technology of the TinyLine provides some basic tools.  Basic path rendering and besorker rendering, text rendering, other color, solid colors, bitmap colors,  provides the field and stroke and datum operation, all basic stuff you need to expect for the 2D library.  Of course, it provides anti-alaska in opacity and left and right text layout.  A couple of words about drawing pipeline.  It's pretty straightforward.  So I think if you're interested in it, you can look at it later on.  It's not very complicated.  2D library supports painter models when you all concessive operation paint one over another.  It supports different coordinate spaces like user space, text space, device space, pretty similar to the PDF model.  It supports, of course, text fonts and colors.  A TinyLine SVG build on top of 2D library and supports basically SVG Tiny11 plus engine, which includes SVG fonts,  different raster images, text elements, smile animation and events.  It has very easy to use API.  Similar pipeline, which includes the 2D pipeline.  It's just generally show the flow from the text input to SVG input stream,  going through the build SVG document and then resurrect the 2D pipeline.  It was very easy to make TinyLine run on the Google application engine  because TinyLine doesn't use AWT or Java 2D for rendering.  So it's no classes to depend on and no peers or whatever connection to the hardware.  So it was ported very pretty fast.  So this was missing, which is missed also in the Google application engine  and how you can import the PNG graphics, for example, or GPAC graphics into a Java environment of the Google application engine,  or you can write or export PNG graphics.  All these drivers on the standard Java environment, they're written on native code.  They are part of AWT.  This part was missing and implemented pretty fast.  And 2D and SVG canvases were implemented to run in the Google application environment.  And this is a list of these classes.  Now they talk about basic demos.  First, it comes to the two sets of the examples.  The two examples show the basic drawing operations, so we can basically switch to the real web application,  running on the Google application engine.  Wow.  I can't see too much.  For example, this drawing of the reserve curve.  I can see it.  It's coming.  And here's drawing of the different gradients.  Also coming this image in the middle.  It's generated on the Google application engine exported to PNG.  The whole list of these examples have pretty much every feature of the 2D engine, so you can check it out.  The next example is SVG drawing service, so you can upload your SVG file  or make a link to SVG resource and have PNG images generated on the fly.  So this example, for example, the image generated three different sizes.  Also, you can play online.  This, for example, we can draw 400. It's too much. Let's draw it.  And 200.  And here they've gotten the PNG generated on the Google application engine infrastructure.  And the side effect of the tiny line running on the Google application engine  allows other applications that are using SVG to run on the same Google application engine.  For example, I took barcode application and made a driver that draws the barcode using tiny line infrastructure.  And as well, generate barcode using Google application infrastructure.  For example, generate barcode like that.  These are the basic examples for using tiny line on the Google application engine.  More advanced example came up when I heard the...  Sorry.  Next one is about storing and searching SVG files using Google application engine.  The idea was just to evaluate technology to upload the SVG files into the Google application database  and try to search them and to use tiny line as a tab nail services  which allows to evaluate technology for drawing a lot of...  directory of SVG files using tab nail images and to present directors of SVG like type nail images  and the result of the search as a list of the tab nail images.  And basically it's better to see that.  So the real application.  So what you see is a list of tab nail images and all images sitting on the database of Google application engine.  So user can upload the new images.  He can provide some description or caption for it.  You can edit it or download or delete it.  Also you can search this database, so called database because it is more for example for...  for keywords.  And you get some subset or result of the search that has SVG because SVG presented as text, as XML text.  So with one year when the user upload the SVG file into the database,  SVG arch application just grab all the text nodes from the SVG, make some stamina on it  and store the search, they call the search map into the database.  And later you can pretty fast find out the images for the keywords.  So basically now I talk about limitation because I have maybe 5 minutes, right?  A bit more.  Basically limitation of the approach presented because the Google application engine has some limit of the size of the entry.  You can put in a big database like 1 megabyte but it's enough for a lot of SVG images.  It's reasonable size, it's enough.  And if it's not, it could be changed.  You can use several entries for one file.  And number of searching terms, it's limited to around 5 because we use the basic full search approach, not full blown library.  And in the reading part it supports SVG tiny 1.1 plus which is limitations not like SVG 1.1 full.  And natural future development could be support of the SVG tiny 1.2 and SVG 1.1.  Oops.  Okay.  Just lost the visual.  Okay, never mind.  Nothing actually to show.  And development of the search robot which can crawl the Internet and store the SVG images into the database.  Now ready for questions.  Thank you.  Thank you.  We have a 5 minute for questions.  I have a couple of questions for you.  Why did you use Google App Engine M.0 S3 from Amazon for example?  First it's because it's written in Java and it was very easy to jump in.  It's a lot of easy. I investigate the Amazon EC engine and find it more difficult.  And now the question.  The second question is why did you target a so small part of SVG and what was your goal at the beginning to embrace the biggest subset?  This limitation of the tiny line library because it's currently support just SVG tiny 1.1.  And it was historically limited to the size because the target, the previous target was mobile devices and it's going for the mobile devices.  Actually I was thinking to use Bateek as a front end and the tiny line as a back end like render for Bateek doing all the preprocessing like CSS and SVG 1.1 support.  But actually drawing to be done using tiny line.  And this way I can make it bigger.  Okay, so thank you very much. Thank you.
Drawing_SVG_in_the_Cloud_2_0_59.png Drawing_SVG_in_the_Cloud_2_60_167.png Drawing_SVG_in_the_Cloud_2_168_707.png Drawing_SVG_in_the_Cloud_2_708_2459.png Drawing_SVG_in_the_Cloud_2_2460_4727.png Drawing_SVG_in_the_Cloud_2_4728_6479.png Drawing_SVG_in_the_Cloud_2_6480_11183.png Drawing_SVG_in_the_Cloud_2_11184_11675.png Drawing_SVG_in_the_Cloud_2_11676_13379.png Drawing_SVG_in_the_Cloud_2_13380_13463.png Drawing_SVG_in_the_Cloud_2_13464_13523.png Drawing_SVG_in_the_Cloud_2_13524_13883.png Drawing_SVG_in_the_Cloud_2_13884_15503.png Drawing_SVG_in_the_Cloud_2_15504_16391.png Drawing_SVG_in_the_Cloud_2_16392_17351.png Drawing_SVG_in_the_Cloud_2_17352_18671.png Drawing_SVG_in_the_Cloud_2_18672_19139.png Drawing_SVG_in_the_Cloud_2_19140_20363.png Drawing_SVG_in_the_Cloud_2_20364_20531.png Drawing_SVG_in_the_Cloud_2_20532_21167.png Drawing_SVG_in_the_Cloud_2_21168_21299.png Drawing_SVG_in_the_Cloud_2_21300_22943.png Drawing_SVG_in_the_Cloud_2_22944_23027.png Drawing_SVG_in_the_Cloud_2_23028_24647.png Drawing_SVG_in_the_Cloud_2_24648_28979.png Drawing_SVG_in_the_Cloud_2_28980_29039.png Drawing_SVG_in_the_Cloud_2_29040_29079.png