[mcclim-devel] OpenGL backend

[Bastian Müller]

Robert Strandh wrote:

Hi,

> patrice.lespagnol at obs-nancay.fr writes:
>  > 
>  > I'am interessed in using the OpenGL backend of McCLIM : what is its state
>  > currently ? What would be a good start point to work on it ?
> 
> The state is that it hasn't been worked on for a number of years, and
> that it is unclear how much of it is working.
> 
> Your best bet would be to send email to moore at bricoworks.com or
> simply to experiment with it to find out what is working and what
> isn't.  

After seeing some conversations about the OpenGL backend at #lisp and
finally here, I'd really like to get some people together to work on it.

The current OpenGL backend is based on CLX' OpenGL bindings. Currently
there's far more activity at the cl-opengl project, which is more lispy
and cross-platform, ie. not bound to X. McCLIM should use that instead.

I really like Inertia (http://www.mike-austin.com/inertia/), which is a
OpenGL based User Interface written in different languages, like Ruby
and Dylan. The code is small, simple, very clean, really good
comprehensible. Porting the snippets should work easily.

Reading http://kantz.com/jason/clim-primer/application-frames.htm:
"
Frame Managers
--------------
    * control the realization of the look and feel of a frame
    * interpret the specification of the application frame in the
context of the available window system facilities
    * take care of attaching the pane hierarchy of an application frame
to an appropriate place in a window hierarchy

Kinds of Frame Managers
-----------------------
    * desktop manager or window manager
          o allows a user to manipulate the frames of other applications
          o is usually a non-Lisp application
          o acts as a mediator between the Lisp application and the host
desktop manager
          o application acting as frame managers
          o allow frames of other applications to be displayed within
the host application
"

I'd like to use the OpenGl backend both in two "modes":

a.)  for each frame: ask the window manager to get a window (via glut)
and draw the frames contents (text, buttons, ... ) inside the window.
That's how the CLX and gtkairo backend work.

b.) ask the window manager for *one* window (via glut) and for each
frame draw a "window" (in the glut window) it's contents. That's what
inertia  does.

Does a CLIM frame-manager support these modes or is the spec just based
on the concept a.)? If both are possible:
What mode is more favorable? Or work on both and have a common code base?

For fonts ZPB-TTF (http://www.xach.com/lisp/zpb-ttf/) should be used,
it's native lisp and works very well.

For graphics there are two possibilities:

a.) software-based: Vecto (http://www.xach.com/lisp/vecto/) is great for
vector graphics. Don't know what to use for bitmaps.

b.) hardware-accelerated: as we're already working with
hardware-accelerated 3D graphics, we could also use hw-accelerated 2D
graphics. There's the unfortunately unknown OpenVG
(http://www.khronos.org/openvg/) specification, available from Khronos,
the consortium that also makes OpenGL. There are some open-source
implementation, the best being currently ShivaVG
(http://ivanleben.blogspot.com/2007/07/shivavg-open-source-ansi-c-openvg.html)
written in C and based on OpenGL. It's simple, fast and has at least
most  of the functionality needed. I've written a cl-opengl-like wrapper
library cl-openvg, which works very well.

I really like CLIM and it's features, but both gtkairo and CLX are not
cross-platform and not appealing. With OpenGl both is possible. If we
make McCLIM pretty and cross-platform, it'll attract more developers and
users

So, anyone interested in this possible project, please comment and give
feedback. Any help is appreciated.

Thanks!

kind regards,
  Bastian