macrominds

When I searched for a Swing Component that is able to render modern HTML/CSS, I noticed that there’s no solution that covered all of my needs. Here are my thoughts on the topic and an (unfinished and rough) idea on how to create a JWebPane while the original JWebPane (announced 2008) stays vaporware.

A year ago, I wanted to use a browser-component in a translucent / shaped Swing window. After a whole lot of research, I decided to try DJ Native (I wrote an article on this as well).

In short: No support for translucent windows. I haven’t found a solution for this requirement. The project then switched away from HTML/CSS in favour of JavaFX, so I didn’t mind for a long time.

Now I’ve got the same requirement again.
Again I searched the web for solutions and found nothing appropriate for Swing.

There seems to be a solution for SWT though (that seems to cover the main OS Linux, Win and Mac OS). Well, I don’t want to use SWT right now for several reasons, so I didn’t dive deeper into this topic. Besides, there are several prerequisite requirements, that simply don’t fit the usual scenario.

I found several approaches for the problem of having a Swing component for displaying HTML/CSS:

Use native Renderer

This is the preferred solution if you want to have your component stay up-to-date and display modern webpages. However, there’s no way to use that in Swing without problems (especially in translucent windows). This is partly caused by the lightweight / heavyweight issue in Swing (or simply the nature of Swing versus native display). (See the link under “Other approaches and thoughts” below or the discussion concerning DJ Native Swing for more info on this)

100% pure Java

The solutions are often pure Swing, so no problems here, but all of them lack the ability to render modern pages. Most of them don’t even display better than IE 5.5. (for example due to the lack of displaying background-images or other issues). I found no solution that was even slightly able to render CSS3-styled pages.

Other approaches and thoughts

Here’s a good list of approaches for an embedded Browser in Netbeans.

One approach, that I really liked, was the one of Cobra. It parses and interprets HTML/CSS, creates a DOM-Tree and provides methods for accessing the attributes and calculating the absolute coordinates of the elements. However, Cobra relies on its own Java-Implementation and thus lacks the great standards compliance and “up-to-date”ness of gecko or webkit.

So what I thought about is the following idea.

• Use Webkit or Gecko as an external native lib, just for parsing and interpreting and logically laying out the components. Clearly, this only works if the engines provide a logically layed out dom or scenegraph. (I didn’t manage to get a closer look at the engines yet).
• Provide a JNI for receiving the DOM, handling URL-resolution (client apps may or may not have this requirement), user interaction and forward events.
• Write an own renderer, which walks through the scenegraph and stupidly renders the elements using the absolute coordinates and calculated attributes using Java2D and Swing.
• Write java-based interaction manager, that forwards interaction-events to the engines’ DOM-tree

While it would be a lot of work to write the renderer (especially for CSS3 stuff like multiple backgrounds, web-fonts, shadows, etc) and it’s unclear how both worlds would interact on stuff like animations / transitions, this is IMHO the only way to get a real Swing-Component, that keeps up-to-date (well, the renderer itself would need updates as well, but I think the main work on keeping up-to-date is the logical engine).

The downside is, that such a component would never be able to render plugins like Flash, etc. in the Swing-Way. They will always be required to be displayed natively.