1 |
On 2009-04-26, Fabian Groffen <grobian@g.o> wrote: |
2 |
> On 08-04-2009 15:13:53 +0000, Dirk Tilger wrote: |
3 |
>> On 2009-04-07, Fabian Groffen <grobian@g.o> wrote: |
4 |
>> > Is there anything that would break if we remove this symlink? And does |
5 |
>> > it make sense to have both mesa and apple-opengl installed? I thought |
6 |
>> > mesa provides an opengl implementation? I'm not to familiar with this |
7 |
>> > stuff, so please tell me if I'm wrong. |
8 |
>> |
9 |
>> Hi Grobian, |
10 |
>> |
11 |
>> well, to be honest, I'm not deep into this either. "osmesa.h" declares |
12 |
>> functions in /usr/X11R6/lib/libOSMesa.dylib, which is not currently |
13 |
>> included in apple-opengl, so it wouldn't really change something if we |
14 |
>> omitted it. Both header and library are not part of the OpenGL standard |
15 |
>> and but provide additional functionality (offscreen rendering). |
16 |
> |
17 |
> Ok, have you tried if stuff works with modified apple-opengl not to |
18 |
> provide osmesa.h? If so, I'm happy to remove the file from the ebuild. |
19 |
|
20 |
No, in fact I haven't any OpenGL application coming with an ebuild that |
21 |
compiles on my box. ;) But I can provide strong evidence: |
22 |
|
23 |
| dirk@Snake ~ $ for PROC in `grep ^OSMesa /usr/X11R6/include/GL/osmesa.h|sed 's!(.*!!'`; do for LIB in `equery f apple-opengl|grep dylib`; do grep -H ${PROC} ${LIB}; done; done |
24 |
| dirk@Snake ~ $ |
25 |
|
26 |
None of the methods defined in /usr/X11R6/include/GL/osmesa.h are |
27 |
used or provided in any of the libraries in apple-opengl. ;) |
28 |
|
29 |
I think the ebuild needs a few more changes: It's symlinking GL dylib's |
30 |
from /System/Library/Frameworks, which might have side-effects. |
31 |
|
32 |
As I came to understand OpenGL, it is a setup of platform independent |
33 |
graphics routines that is used together with a set of platform dependent |
34 |
setup routines. GLX provides the setup routines when OpenGL is used with |
35 |
X11, AGL provides the setup routines when OpenGL is used with Quartz. |
36 |
There are others for all kinds of other environments including Windows. |
37 |
|
38 |
/usr/X11R6/README says on my system: |
39 |
| Direct rendering has exactly the same performance as the native Mac |
40 |
| OS X OpenGL framework. Indirect rendering also uses the native GL |
41 |
| implementation, but incurs the penalty of marshalling, transmitting |
42 |
| and unmarshalling all GL primitives. |
43 |
|
44 |
I take from that paragraph is what they do is they are translating the |
45 |
X11 OpenGL calls into Quartz OpenGL calls. That's probably why `otool -L |
46 |
/usr/X11R6/lib/libGL.dylib` shows it has linked |
47 |
|
48 |
/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib |
49 |
|
50 |
When I look at the symlinks of media-libs/apple-opengl-2, I see some |
51 |
pointing to /System/Library/Frameworks. I believe since GLX is the |
52 |
classical Un*x way of doing OpenGL, we should probably take all OpenGL |
53 |
files from within /usr/X11R6. For the ones that are actually running on |
54 |
Quartz natively (let's say a OpenGL extension for vim ^^), I would |
55 |
expect that they pick the OpenGL using '-framework OpenGL' and then they |
56 |
get the files from /System/Library/Frameworks/OpenGL.framework |
57 |
automatically.. |
58 |
|
59 |
Hope I could shed some more light on this. |
60 |
|
61 |
Dirk. |