Re: [Caml-list] What does Jane Street use/want for an IDE? What about you?

[Jon Harrop <jon@ffconsultancy.com>]

On Wednesday 05 November 2008 15:20:26 Kuba Ober wrote:
> > > Have you ran recent Qt demos distributed with Qt? I'd say they look
> > > pretty cool in my book.
> >
> > They would not have impressed me a decade ago, let alone today. Many of
> > them don't even work on either of my Debian machines.
>
> I have one question regarding OpenGL: maybe it's just me, but isn't core,
> or "historical" core OpenGL blissfully unaware of simple concepts such as a
> path, a brush, stroking a path etc?

That is correct. Smoke already implements all of that:

  http://www.ffconsultancy.com/products/smoke_vector_graphics/?ob

> This was long time ago, but I recall 
> that drawing a circle using OpenGL implies that you (or some middleman
> library) has to discretize the circle into triangles, and then render that.

Smoke uses a much more sophisticated approach based upon anisotropic 
hierarchical decomposition that provides high-performance culling of 
arbitrary vector shapes. So you can feed it a Gb map of the world and use it 
to fly around in real-time without having to write anything difficult 
yourself. You can even apply arbitrary affine transforms to vector shapes and 
it will continue to make maximal reuse of tesselations and cache them on 
graphics hardware if it is available.

> Again, correct me if I'm wrong, but typical OpenGL-based UI rendering
> will do good old antialiased software 2D rendering on OpenGL textures,
> and the composite some simple 3D models with those textures applied.
> [Or it may, at a cost of generating *way more* triangles, use shader
> programs.]

No, Smoke keeps everything in vector form and renders triangles. Smoke can 
also run entirely in software using Mesa and can render PostScript in 
software over an order of magnitude faster than GhostView. But Smoke was 
designed specifically to leverage hardware accelerated OpenGL and it runs 
about two orders of magnitude faster when that is available.

> That way you can get goodies like shadows of text rendered in a window
> with transparent background, but it's really awkward to do directly in
> OpenGL. These days I imagine this "2D" rendering can be done using
> shader programs, but that excludes a lot of commonplace hardware
> outright, and hits some implementation bugs hard (just look around at
> various game forums). And I really don't quite love the idea of
> generating a bazillion triangles for the 3D hardware to then
> shade: I wish 3D hardware could work with splines of some sort (does it?).

The nVidia 9 series is the first hardware to provide decent support for 
splines, AFAIK. Decent support requires vertex creation in-hardware.

> AFAIK/IIRC, as soon as you wish to move to a higher level scene
> description, where basic primitives such as paths live in 3D, you have
> to implement a whole lot on top of OpenGL, and there are no real
> standards as to how to do it. If anything, Cocoa and MPF (?) may be
> examples of how to go about it, but that's a long shot of where
> we'd all like to be.

I don't think it is a long shot at all.

> I would like nothing better than to work with hierarchical interactive
> display representation, where simple things remain simple: say you have
> a letter shown in your text editor widget, and you want to know where
> the said letter is located. With a scene description graph, you can
> extract that information -- the way Qt does it so far either requires the
> text layouter to provide you with relevant API, or you have to plug
> yourself between the layouter and the paint engine and literally listen for
> where the glyphs get painted. The scene description would be easier to use,
> of course. If the scene description has links into the underlying text
> document, as it well should, then it gets even easier.

Smoke already provides a basic form of that functionality. It uses OpenGL 
picking to provide a list of integers that describe the path through the 
scene graph to the nearest shape in the given region. Check out the source 
code to the interactive tiger demo, for example.

> So, please understand that I'm not oblivious to benefits of thinking in
> higher levels of abstraction, but I'm also practical and know that Qt
> provides me with a whole big lot of cross-platform functionality that
> simply doesn't exist anywhere else in one coherent platform.

Maybe if I release Smoke as open source software OCaml will become usable for 
advanced GUI programming. If I don't, I think OCaml is dead in the water in 
this respect.

-- 
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e