Drawing with RAP? Yup!

I have to admit, I’m a little nervous what happens with the RAP community after this post. At least for me, the last days were pretty exciting. Some days ago, Ivan from the RAP team committed the initial support for a GC (GraphicsContext) for RAP. Currently restricted to the Canvas widget, the GC provides thousands of new use cases for RAP applications. The work by Ivan and Tim is just gorgeous and will help many developers to single-source their applications with even less exceptions. In case you want to try it out in this second without reading further, just fire up the RAP Examples demo and draw something yourself 🙂

RAP with Canvas

Credits for the picture above goes to Holger with the aim to come up with a new RAP project logo 😉 After using the GC the first time in the Examples demo, I thought about other possibilities to test the new GC. My first thought: custom widgets? Tired of writing custom widgets in JavaScript? Get your Canvas and single-source your custom widget with RCP by writing an owner-draw widget. But as it was late in the night, I decided to just reuse some existing owner-drawn widgets like those we can find in the Nebula project. After getting the PShelf widget from CVS, it was only a matter of seconds until I started my first RAP application using an owner-drawn Nebula widget:

Nebula PShelf on RAP

And I think I know what most of you are currently thinking – Draw2D, GEF and GMF on RAP? To keep it and short and simple: No! While it may be possible to single source Draw2D with the exisiting Canvas, I’m pretty sure it will not scale. The way Draw2D is implemented will cause major performance problems with the browser-side Canvas widget. As I said, it may be possible but not really preferable. For supporting Draw2D the right technology on the client-side is there. Only on the server-side we would need APIs that entirely hide the GC. Thus we could directly translate from one vector-based technology to the other.

I’m pretty excited to see how the community can profit from the new Canvas implementation. Want to try it out? Either get the current RAP runtime from CVS or wait some days until we can publish RAP M7 (which has several other cool new & noteworthy items).

  • Posted at 15:39, 2010-04-20


    I’m thoroughly impressed… however, what are the browser limitations on this widget?

  • Posted at 16:01, 2010-04-20

    Wow, that’s a great step forward! Very cool! And gives access to Nebula widgets on RAP for free!

    Although it cannot be applied for draw2d & co, it clearly shows that HTML5 Canvas opens a lot of perspectives on this topic. Maybe a client-side org.eclipse.draw2d.Graphics implementation could do the trick?

  • Ugo
    Posted at 15:12, 2010-04-20

    Hey Benjamin, Im also amazed about having a GC in RAP, I wonder when we’re able to provide live feedback about dragging, we could be able to do some sort of Sketch for web!
    Like https://www.youtube.com/watch?v=TgPYc-Z2mVE

    real nice

  • christian campo
    Posted at 17:43, 2010-04-20

    Pretty cool Benji, I cant wait until Elias (who is currently trying) uses it on Riena and we see if it does any good to navigation bar, that has a lot of GC in it.

    many kudos for the step RAP is taking in Helios. Really a big step forward !!!!

  • Patrick
    Posted at 17:55, 2010-04-20

    Great job! This is really powerful, even if limited by the client-server round trips…

  • Lars Vogel
    Posted at 21:56, 2010-04-20

    Congratulations to this milestone. RAP is getting cooler and cooler. I hope to see this demo in the Mannheim Democamp. 😉

  • Mark
    Posted at 01:40, 2010-04-21

    The one big thing have been needing is the the calendars from Nebula.

  • Posted at 19:21, 2010-04-21

    Hmm…what about GEF3D? I can’t help but note out that GEF3D has great support for vector text (!) and (obviously) supports the GEF2D API. I’m not sure enough about internals to know if this will really work — and I have no idea what the OpenGL support is like on the majority of browsers out there — but I’m going to see what those guys think.

  • Jens v. Pilgrim
    Posted at 18:25, 2010-04-23

    Since Miles mentioned GEF3D, I’d like to add some comment, too 😉 Benjamin wrote, in order to get GEF/Draw2D working with RAP, we’d need a server-side API hiding the GC. Actually, GEF3D comes with new implementations of Draw2D’s Graphic interface and adds a new Graphics3D interface. There are three different implementions of these interfaces: two using OpenGL to create the output (LWJGL and JOGL), and one for exporting 3D drawings to X3D. IMHO, the most interesting thing is the (2D) Graphics implementation of DRaw3D (created by Kristian Duske). It does a lot of tricky optimizations in order to reduce the amount of data send over the BUS (to the graphics card). While client-server communications is certainly different from that, I could imagine that a similar approach could be useful in that context as well — maybe Kristian’s implementation could be used as a starting point.
    Only recently I tutored a master thesis about getting GEF3D to the Web via RAP and WebGL(as I already sent the thesis to Benjamin, this is more to complete by reply 😉 ). Unfortunately, due to the large number of APIs (WebGL, RAP, Qooxdoo, OpenGL/WebGL, GEF/3D, Draw2D/3D), we could only create a prototype instantiating a WebGL based 3D view in a RAP based application, but I could image that at least 3D viewers based on that technologies (i.e. RAP+GEF3D+WebGL) should be possible. Actually, it should be as easy (or even easier) as the RAP+GEF+Canvas stack. As we have already a prototype instantiating all the RAP and WebGL things, all you need to implement is the Graphics3D interface. As far as I know Kristians Graphics implementation, most optimizations do not depend on the actual renderer.

  • Mirko Solazzi
    Posted at 15:18, 2010-09-05

    I think it is very important adding the Image creation feature on RAP.
    For example if I need to create a captcha image for user registration, or if I need to create a graphic (static image) without drawing on the canvas.
    It is sufficient to make the Image class “Drawable” and extend GC class method: the behaviour remains the same for instances of “Control” type while for “Image” instances you should implement the graphical operations on server memory, modifying the ImageData pixels [before saving it into a resource file] or using the native SO graphical operations inside the additional server display (X-Window) like the standard SWT does.
    I do it in my web applications, by importing the original SWT package (I take the native libraries, depending on the server SO where the application server runs) and by creating images with a servlet. I cannot do the same with RAP because it overrides the SWT Image/GC classes.