[Kalzium] Fwd: OpenGL availability

[Carsten Niehaus]

I am forwarding this to the mailinglist to get more opinions.

----------  Weitergeleitete Nachricht  ----------

Subject: OpenGL availability
Date: Montag 12 Juni 2006 10:24
From: Benoit Jacob <jacob at math.jussieu.fr>
To: Carsten Niehaus <cniehaus at gmx.de>

Hi,

I was reading the comment "OSV Comment - OpenGL / Thin-Clients" on your
blog entry and it makes sense: here at my math department we have thin
clients connecting to Red Hat and fedora servers, and OpenGL is disabled.
Not even software rendering with MESA.

On computers being their own X server, we can always assume that there
will be some OpenGL implementation, at least software-only. But for
systems depending on an external X server, it's different.

Normally, the OpenGL shared libraries are always installed,
even in environments where OpenGL is disabled. That's the case at my
office. (I hope that's the case everywhere, not 100% sure here)

Which means that it should be safe to link against OpenGL shared
libraries, there should be no problem at Kalzium startup. The problem
only will appear when the users will try to open a KalziumGLWidget.

We can (and must) check OpenGL availability at runtime, Qt provides a
method for that (I think, hasOpenGL).

In case there is no OpenGL, the question is, what do we do?

I don't think we have to give up and display "sorry no candy for you".

First, there's the png drawing you've already implemented. You might
consider it a good fallback and perhaps you want to do the same for the
molecule viewer.

Another possibility is to do some advanced 2D drawing with Qt. I'm willing
to do that if you want, I only want to first implement the GL drawing, but
later I'm willing to learn Qt painting enough to do it.

All what one really needs from Qt is basic drawing functions like drawing
a filled, rotated rectangle and a filled circle. The rest is math and I
can do it. I could emulate simple perspective (as when you draw a
cube on paper), and of course no lighting or fog effect. I would draw the
objects farthest-to-nearest in order to compensate for the lack of
a depth buffer.

On the other hand, that would be a lot more code in Kalzium, to address
only a special case.

What do you think?
Benoit

-------------------------------------------------------

-- 
Gruß,
  Carsten Niehaus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kalzium/attachments/20060612/07282af2/attachment.pgp