RHQ d3.js Graphing Solutions for IE8

mike thompson mithomps at redhat.com
Tue Sep 25 03:06:34 UTC 2012


On Sep 24, 2012, at 11:42 AM, Charles Crouch <ccrouch at redhat.com> wrote:

> Before we abandon charts in IE8 all together I would like to better understand Mike's recommended solution, i.e. server side rendered images via a java library. 
> 
> - How far are we away from having an implementation for people to test drive?
	Clean up Base charts: 1 day
	Implement: 1 day with possible 1-2 day to fix specific rendering issues

> - What overhead does the image generation add to the RHQ server? How quickly will those images appear for users?
	This is unknown. I can't imagine it would be much. However there would several charts rendered simultaneously on the dashboard view

> - Can you provide some specific examples of what you mean when you say the IE8 version will "lack the interactivity" you'll get on other browsers. Would we end up with something that people would actually still want to use? i.e. will it be better than nothing? How does this compare to what we have today?
	Non-interactive refers to a jpeg version of the chart. So it is a static solution with no interactivity via clicking and hovering but you still have a graphical representation of the information.

> - Am I right in thinking this approach would only require a single "charting code-base"? i.e. as the charting implementation evolved would we just have one place to update and fix bugs regardless of browser being used? [Assuming the bugs weren't in the server-side image rendering code itself]
	Yes, this would be a single code-base solution as the SVG chart representation would just get rendered on the server-side (Batik) instead of on the javascript client.
> 
> Thanks
> Charles
> 
> ----- Original Message -----
>> 
>> 
>> 
>> 
>> Sorry for the top post - rather than dropping support for IE8 could
>> you just exclude the graphs from the UI when viewed with IE8?
>> 
>> 
>> 
>> 
>> 
>> On Sep 20, 2012, at 1:17 PM, mike thompson < mithomps at redhat.com >
>> wrote:
>> 
>> 
>> 
>> 
>> RHQ d3.js Graphing Solutions for IE8
>> 
>> 
>> The Problem :
>> 
>> 
>> As part of the Google Summer of Code project to replace the graphs in
>> RHQ, d3 ( http://d3js.org/ ) was chosen as the charting framework.
>> One problem remains however, the d3.js visualization (graphing)
>> library does not support IE8. More specifically, IE8 has gaps such
>> as: DOM manipulation issues, no SVG support, no Canvas support along
>> with various non-standard compatibility issues. Typically, a d3
>> graph is rendered as a SVG or Canvas solution depending upon the
>> chart type or chart library sitting atop d3. d3 is essentially, the
>> framework from which, other d3 chart libraries are built -- a
>> library can have one or more chart types.
>> 
>> 
>> The d3 author (Mike Bostock) has targeted the html 5 browsers as it
>> keeps the codebase clean and manageable. Eventually, the older
>> browser base will wither away anyway. There are however, numerous
>> options for getting around this, each with their own strengths and
>> weaknesses.
>> 
>> 
>> 
>> 
>> Background :
>> The users of the Windows XP (End of Life: 2014) are stuck at an IE
>> version of 8 and have no upgrade path.
>> And yes, some enterprises do still use Windows XP, even though Google
>> applications just announced they will be dropping support of IE8.
>> 
>> 
>> 
>> 
>> Possible Solutions :
>> 
>> 
>> 
>>    1. Develop without SVG. Pure HTML/CSS charts
>> 
>> 
>>        1. This would work for IE8 but could only use bar charts,
>>        candlesticks or whisker charts; basically anything that can
>>        be created with a div and some fancy css
>>        2. IE8 would get a separate code base with different looking
>>        charts than other portions of the app
>>    2.
>> Build the visualization server-side and just add interaction on the
>> client side
>> 
>> 
>>        1. This would mean a server-side graphing solution like
>>        jFreeChart
>>        2. interactions would be primitive on the client side
>>    3.
>> Use an abstraction over different rendering engine (Dojo.GFX,
>> Raphael, Three.js)
>> 
>> 
>>        1. This could also work as d34raphael will work for IE8 on
>>        Windows 7 but not on XP (different version of IE)
>>        2. d34raphael is an forked version of d3 to work with raphael
>>        so not everything in d3 has been ported and we could get
>>        left in the dust not too far out in the future along with
>>        some standard d3 things not working
>>    4.
>> Use HTML5 Canvas. svg --> canvas
>> 
>> 
>>        1. no evidence that this would work (did some prototype work
>>        with ex-canvas; most d3 charts are SVG anyway)
>>    5.
>> Use shims and polyfills , but I don't know of any that works easily
>> for interactive stuff
>> 
>> 
>>        1. This was my initial preference and I spent 2 days trying
>>        various techniques out -- to no avail
>>        2. svgweb did not work
>>        3. SIE SVG did not work
>>        4. Flash Canvas did not work
>>        5. excanvas did not work
>>        6. [I feel like I have exhausted the polyfill options that
>>        looked so promising at first]
>>    6.
>> Make it static on IE and the full UX on real browsers (
>> https://groups.google.com/forum/?fromgroups=#!searchin/d3-js/d3$20ie8/d3-js/XHbidy5pY8A/7b7rbP7iUIUJ
>> )
>> 
>> 
>>        1. Send SVG to Apache Batik java library on the server to
>>        render ( visual.ly is using this in production)
>>        2. Use Phantom.js ( https://github.com/ariya/phantomjs ) to
>>        render svg --> png in javascript
>>    7.
>> Drop IE support
>>    8. Use Google Frame to render SVG inside of Internet Explorer
>>    9. Write two codes: SVG and VML. Do VML work in d3 out of the
>>    box?
>> 
>> 
>>        1. Nobody uses VML anymore
>>        2. the VML to represent SVG would be non-trivial (SVG is hard
>>        enough)
>>    10.
>> Leave the current graphing solution in place, but just for IE8.
>> 
>> 
>>        1. This means that we can't get rid of portal war.
>> 
>> 
>> 
>> 
>> 
>> Recommended Solution :
>> 
>> 
>> Looking at supportability, the future, and robustness of the
>> solution…Batik svg rendering on the server side (using java) seems
>> like a good solution for filling the IE8 compatibility issues with
>> the same looking graphs just that they will lack the interactivity
>> that full d3 version
>> 
>> 
>> Batik ( http://xmlgraphics.apache.org/batik/ ) is a well known,
>> established SVG rendering library that is written in java. We know
>> how to support java much better than a javascript solution and
>> because it is server side java the performance will be better as
>> well. The implementation of this could even be a REST resource that
>> takes in SVG and streams a binary PNG or JPG.
>> 
>> 
>> Fallback Solution :
>> For IE8 don't use d3 SVG but instead use d3 pure HTML/CSS charts .
>> This limits us to bar graphs but they can still be good looking bar
>> graphs; essentially css styled divs.
>> 
>> 
>> 
>> 
>> 
>> 
>> "IE8 is the new IE6"
>> 
>> _______________________________________________
>> rhq-devel mailing list
>> rhq-devel at lists.fedorahosted.org
>> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
>> 
>> 
>> _______________________________________________
>> rhq-devel mailing list
>> rhq-devel at lists.fedorahosted.org
>> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
>> 
> _______________________________________________
> rhq-devel mailing list
> rhq-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel



More information about the rhq-devel mailing list