====== HOWTO: Hacking seamless SVG background tiles ======= Image creation/manipulation is an essential part of UI design and, with Photoshop gone, GIMP and Inkscape came to the rescue. Almost all graphics used in the Apollo-NG realm are created with Inkscape. With many people already using Inkscape and it being a vector oriented tool creating SVGs, it was just a matter of time until the [[http://www.w3.org/Graphics/SVG/WG/wiki/Secret_Origin_of_SVG|SVG standard]] and its implementations matured and spread. Some features, such as SMIL animation and SVG Fonts are not as widely supported. There are many SVG authoring tools, and export to SVG is supported by all major vector graphics authoring tools. {{ :mission:log:2015:04:06:svg-seamless-background-hacking.jpg |}} SVG 2 is currently under development, and will add new ease-of-use features to SVG, as well as more closely integrating with HTML, CSS, and the DOM, and deprecating features not supported by all browsers. The SVG Working Group is currently working in parallel on a set of modules for extending prior specifications and adding functionality to CSS, and the new SVG 2 specification will combine those modules with the rest of the SVG framework to work across the full range of devices and platforms. Let's see about bypassing even Inkscape and learn with a simple real-world example about programming UI elements directly, as opposed to manually drawing in Inkscape and thereby giving our code the means to control the design itself, making another step towards better SDUI. ===== The Pixel inheritance ===== For a long time, GIFs, JPGs and PNGs were the dominating image formats for the web. Take a look at the H1 and H2 elements of this mission log for example: This used to be a PNG image, providing a seamless 45° angled pattern, which the browser (told by CSS) is to repeat on the x axis to fill the background space, which is much larger than the basic image itself, so we could get away with having a 500 byte sized pattern object to reduce bandwidth and page loading time while still giving the element a somewhat more natural contrast, instead of just a plain background color fill. background: #3F3E3A url(/lib/tpl/apollo/images/panel_bg.png) repeat-x; **What are the problems with that solution?** * Pain to Maintain (No vector information) * Rendering becomes fuzzy on HD displays since it's a pixel based image * Zooming in is even worse for the same reason ===== The SVG approach ===== In order to understand SVG/browser interaction and current limitations better, this simple PoC Demonstrator was created to see if it is indeed possible and feasible to substitute pixel based assets with in-css SVG asset delivery. The following two websites have been very helpful as a reference: * http://tutorials.jenkov.com/svg/ * https://docs.webplatform.org/wiki/svg/tutorials/smarter_svg_animation ==== Basic PoC Demonstrator ==== Let's start with a simple, contrast rich pattern of yellow and blue stripes and test if we can indeed use this SVG code to produce a background pattern we can repeat with CSS. === Source === If you want to follow along, put this code into a file, save it with a .svg extension and open it in a browser or Inkscape. It should give you a 20px x 20px image with a 10px wide yellow and a 10px wide blue strip. Start playing with it, change some parameters and hit F5 to reload in the browser after you've saved your changes. === Base64 encoding === Unfortunately we cannot use this code directly in CSS, we have to encode the SVG source code with base64 in order to have a way to integrate into a stylesheet. On any GNU/Linux flavor you're almost certainly already equipped with the required tool for that (base64) $ cat tilebg.svg | base64 -w0 PHN2ZyAgICAgICAgICAgIHdpZHRoPSIyMCIgaGVpZ2h0PSIyMCIKICAgICAgICAgICAgICAgIHhtbG 5zPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwL3N2ZyIKICAgICAgICAgICAgICAgIHhtbG5zOnhsaW5r PSJodHRwOi8vd3d3LnczLm9yZy8xOTk5L3hsaW5rIj4KCjxkZWZzPgoKICAgIDwhLS0gRGVmaW5lIH RoZSBzdHJ1Y3R1cmUgb2YgdGhlIHBhdHRlcm4gdG8gcmVwZWF0IC0tPgogICAgPHBhdHRlcm4gICAg aWQ9InN0cmlwZXMiCiAgICAgICAgICAgICAgICB4PSIwIiB5PSIwIgogICAgICAgICAgICAgICAgd2 lkdGg9IjIwIiBoZWlnaHQ9IjIwIj4KCiAgICAgICAgPCEtLSBDcmVhdGUgYSB5ZWxsb3cgc3RyaXBl ICgxMHgyMCkgZm9yIHRoZSBsZWZ0IGhhbGYgLS0+CiAgICAgICAgPHJlY3QgICB4PSIwIiB5PSIwIg ogICAgICAgICAgICAgICAgd2lkdGg9IjEwIiBoZWlnaHQ9IjIwIgogICAgICAgICAgICAgICAgcng9 IjAiIHJ5PSIwIgogICAgICAgICAgICAgICAgc3R5bGU9InN0cm9rZTogbm9uZTsgZmlsbDogI2ZmZj UzMzsiLz4KCiAgICAgICAgPCEtLSBDcmVhdGUgYSBibHVlIHN0cmlwZSAoMTB4MjApIGZvciB0aGUg cmlnaHQgaGFsZiAtLT4KICAgICAgICA8cmVjdCAgIHg9IjEwIiB5PSIwIgogICAgICAgICAgICAgIC Agd2lkdGg9IjEwIiBoZWlnaHQ9IjIwIgogICAgICAgICAgICAgICAgcng9IjAiIHJ5PSIwIgogICAg ICAgICAgICAgICAgc3R5bGU9InN0cm9rZTogbm9uZTsgZmlsbDogIzAwNjBhZjsiLz4KCiAgICA8L3 BhdHRlcm4+Cgo8L2RlZnM+Cgo8IS0tIENyZWF0ZSBhIHJlY3RhbmdsZSB3aXRoIHN2ZyBpbWFnZSBz aXplICgyMHgyMCkKICAgICBhbmQgYXBwbHkgdGhlIHN0cmlwZXMgcGF0dGVybiB0byBpdCAtLT4KPH JlY3QgICAgICAgICAgIHg9IjAiIHk9IjAiCiAgICAgICAgICAgICAgICB3aWR0aD0iMjAiIGhlaWdo dD0iMjAiCiAgICAgICAgICAgICAgICByeD0iMCIgcnk9IjAiCiAgICAgICAgICAgICAgICBzdHlsZT 0ic3Ryb2tlOiBub25lOyBmaWxsOiB1cmwoI3N0cmlwZXMpOyIvPgo8L3N2Zz4K Technically we could use the above output directly but when you look at the base64 you'll immediately recognize that there are a couple of recurring patterns there. Most of this is unnecessary white-spaces, CRs and comments which we don't really need, so lets use the power of the shell and create a one-liner to compress the code before encoding. We can keep the source files in a structured and readable state with comments/indents and won't have to worry about output size while coding: $ cat tilebg.svg | sed -e :a -re 's///g;/ Not really that much to do as you can see. The only quirk is the fact that we need to play with the output size in order to get the edges to align seamlessly in the CSS pattern repeat so you need to play a little with the output size (in this case 28 worked well). You also have to make sure that the SVG image size at the top is the same as the rect at the bottom for a seamless result. If you've followed along and have the code already in your editor, play around with it to get a better understanding. === Output ===
45° rotated seamless yellow/blue SVG background
==== Customize to suit color-space/identity ==== After we've established that the principle is working and we can easily make changes, it's time to go ahead and try a less eye-cancer prone color combination: === SVG === === Output ===
45° rotated seamless dark SVG background
Great, works as well, but now it's a little too dark. Let's brighten the base colors a bit and also add one highlighted edge at the left and a darkened edge at the right - just barely perceivable - to simulate more depth and a 3D kind of perception. === Output ===
45° rotated seamless dark SVG background
Perfect. From a users perspective it seems way more easy to change a couple of numbers in a text file (or even use variables for them) than to learn some counter-intuitive click path, walking through endless menus to make a small change, similar to the ease of OpenSCAD vs. old-school CAD breeds. But the real benefit is the prospect of SDUI, to be able to cheaply create, inject and alter any kind of UI "design" element on-the-fly by backend or javascript code, thus bringing development and design closer together, which seems similar to a DevOps role to implement and teach software defined infrastructure. Of course there are still a couple of rules about design a developer-designer would have to learn combined with some practice to gain experience. However, the process and necessary things to learn can be broken down and adapted much faster. How will we call this role in the future? DevIgn? Since we know now how to change the image by hand, we can simply teach a computer to do that :) ===== Conclusion ===== It's good to see a growing trend towards software defined user interfaces (SDUI) where we don't waste precious resources to design and produce a specific piece of hardware for humans to interact with directly. This was expensive, slow and inflexible. When we look at modern cars or the upcoming wearables like the LG Watch G R we see devices which provide "intelligent" displays and it's up to the software to draw any user interface we want to display, either a tachometer or a nice watch face. And they can be changed, updated and adapted to anyone's particular needs, if we get easy access to it. UI design practices, especially for websites or web applications, went through a lot of hacks and technologies during the last 15 years. Beginning with simple HTML, frames, "invisible tables", until finally CSS arrived. Back then UI design often was basically drawing something in Photoshop and then "slicing" the big image into many smaller GIFs or JPGs which would be rearranged in tables (no joke!). Interface design has always been just a matter of how to use visual hacks to fool the perceiving eye or to make the process more efficient by manipulating images in the browser, like bg-repeats for example. Now fast forward to the present, where we actually have a plethora of open standards and ready-to-use software stacks to choose from. Based on HTML5, CSS3, JavaScript and modern open browsers like Chromium or Firefox, we can build anything, as long as we have the time to do so. Due to the [[mission:statement|mission's clear demand to go full open-source]], tools like Photoshop (or any other non-free closed-source tool) are no longer available. In the beginning it hurts a lot because many of us probably have spent a considerable part of their lifetime to learn how to use proprietary software first and are simply reluctant to let go of that time investment and learn something new. It should be mandatory for schools and universities to have an open-source software/technology first curriculum, instead of using tax money to buy licences from Microsoft and $else, only to force kids/students to use and train products and workflows of the limited proprietary commercial software ecosphere. And, most importantly: Scalability. When not using sprites, each PNG image is a separate request for browser/server to handle. And in case you're not sure why you want to avoid that, just step back and look at the big picture from an ops point of view here: Let's say a website with 10 PNG UI elements is opened, the browser will get the html (request 1), interpret the html, load the stylesheet (request 2) and then go fetch the other assets (request 3-12) one by one. But each webserver has only a limited number of requests it can handle simultaneously. When you could put your assets directly into the stylesheet, each connection would only perform 2 instead of 12 requests. As a result, the same webserver will be able to handle more than twice as many visitors before maxing out. Additionally, more requests need more CPU, RAM, IO and therefore consume more power, not to mention the required bandwidth and power consumed in-transit by routers etc. This also applies to power constrained mobile devices like tablets or smartphones where battery-runtime is everything. In short, minding these issues will help with: * Performance - Reduced Page Loading time * Energy - Reduced per Visit power consumption profile (server/client) * Scalability - More concurrent users per server This also scales in both directions, if you have a load-balanced multi webserver fronted with thousands of requests per second or just some tiny, low-power embedded system serving only a few clients. It's not perfect yet but it offers a great starting point in terms of flexibility and headroom for optimization. Hopefully, you've enjoyed this introduction/experiment and could learn something from it or at least got some inspiration to solve something else in your particular problem domains. {{tag>svg development sdui design software seamless web css html}} {{keywords>Apollo-NG apollo next generation hackerspace hacker space research development makerspace fablab diy community open-resource open resource mobile hackbus hackbase svg development sdui design software seamless web css html}} ~~DISCUSSION~~