New in Tableau 8: A Quiet Revolution in Rendering
James Baker, Tableau Developer Team Lead, explains why dashboards in a browser in Tableau 8 feel so responsive. This area of innovation on performance is called local rendering, and the team's work on it is pushing the boundaries of what can be done with browsers and HTML5 Canvas technology.
James Baker, Tableau Developer Team Lead, explains why dashboards in a browser in Tableau 8 feel so responsive. This area of innovation on performance is called local rendering, and the team's work on it is pushing the boundaries of what can be done with browsers and HTML5 Canvas technology.
In this interview we dig into the new local rendering feature in Tableau 8: what it does, what it means, and how it evolved.
James Baker, Developer Team Lead on Tableau Server, outside the office in Fremont, Seattle.
What is local rendering?
Local rendering is a new mode of Tableau Server where we are sending data to the browser instead of images. The goal is to create an entirely different feel for our browser client, one that is immediate and responsive and dynamic.
Read down to see a video of interactive filtering with local rendering.
What exactly is happening when we say local rendering?
Local rendering is more about local interactivity. The rendering is just what makes interactivity possible. In the past we relied on server much more for everything- selection, filtering, tooltips. Everytime you hovered over anything, it meant a round trip to the server before we could tell you what it was. Now that data is all there in the browser and we can provide feedback much more quickly and provide more of a desktop-type feel to our web products.
But in fact, Tableau's new local rendering feature includes much more than it sounds: it actually provides a way for Tableau to dynamically decide whether to render locally or on the server, and use that method with no input needed from the user. How does Tableau decide whther to render locally or not?
The best rendering experience varies based on the characteristics of your data, most specifically the complexity of your visualation. Speed is paramount and the amount of data transfered between the server and the client is the largest bottleneck that we have. Most visualizations are simple enough that to transfer the mark-level aggregate data actually costs less than transferring the images that we would otherwise send. However, Tableau always has and does scale up to fantastically complex visualizations, and in that case it’s much faster to send images rather than data because image size does not scale up linearly.
This short video shows incremental filtering in a browser, one of the features of local rendering:
What technologies are you using?
HTML5’s canvas element is our drawing surface.
This seems like something that is really groundbreaking.
This definitely was not possible five years ago. We feel like we are pushing the boundaries of what’s been done, especially as far as the hybrid nature of the work allocation. That’s something we haven’t seen too many examples of.
Browsers as a dev platform have become more and more capable, and we’re on a long term journey to push more and more work and capabilities into the browser client, when it makes sense, in order to give our customers the best experience possible.
How much of a big bet was this for v8?
Considering this idea it was a big change. Informally, I think of this as our v2 web client architecture. Support for local rendering and web authoring-- we needed an architecture that could support both of those features, which both relied much more on local state than our previous architecture.
So this was a big bet, and a joint bet for both of those features.
Did you ever think you wouldn't be able to get it to work?
Yes, we were worried that we would run into technical constraints that would sink us. But with each we went to investigate and were able to solve them. Rendering speed in the browser was a big worry, but turned out to be good enough. Data size was an important concern.
And then the thing I spent the most time working on and thinking about was actually the hybrid work allocation architecture. Many people contributed and the architecture evolved over many developments and learnings.
I’m really proud of what we came up with and the elegance and simplicity of it. Because simplicity is really hard. We took special care to have something simple and understandable enough that we could continue to grow it and add more capability without letting the engineering costs spiral out of control.
In this interview we dig into the new local rendering feature in Tableau 8: what it does, what it means, and how it evolved.
James Baker, Developer Team Lead on Tableau Server, outside the office in Fremont, Seattle.What is local rendering?
Local rendering is a new mode of Tableau Server where we are sending data to the browser instead of images. The goal is to create an entirely different feel for our browser client, one that is immediate and responsive and dynamic.
Read down to see a video of interactive filtering with local rendering.
What exactly is happening when we say local rendering?
Local rendering is more about local interactivity. The rendering is just what makes interactivity possible. In the past we relied on server much more for everything- selection, filtering, tooltips. Everytime you hovered over anything, it meant a round trip to the server before we could tell you what it was. Now that data is all there in the browser and we can provide feedback much more quickly and provide more of a desktop-type feel to our web products.
But in fact, Tableau's new local rendering feature includes much more than it sounds: it actually provides a way for Tableau to dynamically decide whether to render locally or on the server, and use that method with no input needed from the user. How does Tableau decide whther to render locally or not?
The best rendering experience varies based on the characteristics of your data, most specifically the complexity of your visualation. Speed is paramount and the amount of data transfered between the server and the client is the largest bottleneck that we have. Most visualizations are simple enough that to transfer the mark-level aggregate data actually costs less than transferring the images that we would otherwise send. However, Tableau always has and does scale up to fantastically complex visualizations, and in that case it’s much faster to send images rather than data because image size does not scale up linearly.
This short video shows incremental filtering in a browser, one of the features of local rendering:
What technologies are you using?
HTML5’s canvas element is our drawing surface.
This seems like something that is really groundbreaking.
This definitely was not possible five years ago. We feel like we are pushing the boundaries of what’s been done, especially as far as the hybrid nature of the work allocation. That’s something we haven’t seen too many examples of.
Browsers as a dev platform have become more and more capable, and we’re on a long term journey to push more and more work and capabilities into the browser client, when it makes sense, in order to give our customers the best experience possible.
How much of a big bet was this for v8?
Considering this idea it was a big change. Informally, I think of this as our v2 web client architecture. Support for local rendering and web authoring-- we needed an architecture that could support both of those features, which both relied much more on local state than our previous architecture.
So this was a big bet, and a joint bet for both of those features.
Did you ever think you wouldn't be able to get it to work?
Yes, we were worried that we would run into technical constraints that would sink us. But with each we went to investigate and were able to solve them. Rendering speed in the browser was a big worry, but turned out to be good enough. Data size was an important concern.
And then the thing I spent the most time working on and thinking about was actually the hybrid work allocation architecture. Many people contributed and the architecture evolved over many developments and learnings.
I’m really proud of what we came up with and the elegance and simplicity of it. Because simplicity is really hard. We took special care to have something simple and understandable enough that we could continue to grow it and add more capability without letting the engineering costs spiral out of control.
Subscribe to our blog
Tableau の最新情報をメールでお知らせします