Discussion :

[freedom144]

Bonjour,

Je suis face à un énorme problème, j'ai développé une IHM lors des deux dernière année de ma thèse. Cette interface me permet de faire des démonstration de reconstruction 3D.

J'utilise en autre GTK+ et GtkGlExt pour de l'affichage OpenGL le tout sous Windows 7 x64. L'application étant 32Bits, la saturation de la mémoire (1,5G) et souvent atteinte. J'ai donc eu l'idée de passer à la compilation 64bit.

Pas de pb pour la convergence de GTK x64 (http://www.gtk.org/download/win64.php. Mais impossible de trouver de l'aide pour GtkGlExt.

Pouriez vous m'aider..?...

Car le désespoir me guette.... et tout recommencer (sous Qt par exemple) n'ai pas envisageable dans les 6 mois qu'il me reste.

[liberforce]

Bonjour,

GtkGlExt est un composant extérieur à Gtk. Et comme tout projet, sa durée de vie dépend du bon vouloir du mainteneur et de son temps disponible. Tu as commencé à utiliser en 2010 un logiciel dont la dernière version datait de 2006. Cela faisait donc déjà 4 ans qu'il n'était plus maintenu... Ce n'est pas un choix très pérenne.

Par chance, même s'il n'y a plus de nouvelle version, il semble que la maintenance ait continué jusque vers mi-2011. C'est ce qu'on peut voir sur le dépot git de GtkGlExt. J'ai vu qu'il y avait un message de commit parlant de modifications pour MinGW-64, l'environnement qui permet de compiler du 64bits avec GCC pour Windows.

Je te suggère donc de récupérer leur version la plus récente (branche master), et d'essayer de la recompiler sous Windows, avec MinGW-64.

Si tu n'y arrives pas, il ne te reste plus qu'à optimiser ton code pour comprendre pourquoi ton appli utilise autant de RAM. Sous Linux tu as Valgrind pour cela, mais pour Windows, je ne connais pas d'outil gratuit.

[liberforce]

Ah, tu peux aussi demander un peu d'aide sur la mailing list GtkGlExt. Elle n'est plus très active, mais on ne sait jamais...

[freedom144]

Tout d'abord je te remercie de t’être intéresser à mon problème, je sais que ce n'est pas pérenne mais en faite j'ai repris les sources de mon maitre de thèse, sans trop me préoccuper de GTK et encore moins de l'affichage OpenGL.

Pour l'occupation mémoire c'est tout à fait normale vu le traitement que j'effectue, sa pourrait être améliorer mais pas de beaucoup.... d'ou ma volonté de passer au 64bit.

Je te suggère donc de récupérer leur version la plus récente (branche master), et d'essayer de la recompiler sous Windows, avec MinGW-64.

J'ai regarder rapidement et je ne vois absolument pas comment on récupère leur version ni comment tenter de la recompiler ....

[liberforce]

Pour l'occupation mémoire c'est tout à fait normale vu le traitement que j'effectue, sa pourrait être améliorer mais pas de beaucoup.... d'ou ma volonté de passer au 64bit.

Tu vas donc me dire que tu connais très bien la manière dont est consommée ta mémoire ? Je n'y crois pas une seconde, tout bonnement parce qu'on ne peut pas le savoir sans avoir mesuré avec des outils spécialisés. Et vu que tu es dans l'optique de passer en 64 bits, c'est que tu veux contourner le problème plutôt que de te pencher sur ses causes réelles. Si tu n'as pas analysé ta consommation de mémoire, tu ne peux pas non plus savoir si tu n'as pas des fuites mémoire.

J'ai regarder rapidement et je ne vois absolument pas comment on récupère leur version ni comment tenter de la recompiler ....

C'est indiqué tout en bas de http://git.gnome.org/browse/gtkglext/
tu as juste à installer git (msysgit sous windows) et dans ton dossier de développement faire un:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

git clone http://git.gnome.org/browse/gtkglext

Par défaut, tu devrait récupérer la branche master. Dans le pire des cas, il te suffit de rentrer dans le dossier nouvellement créé:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

cd gtkglext

Puis basculer sur la branche master:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

git checkout master

Ce n'est que la première étape, il faudra ensuite le builder, et sous Windows, il faudra sans doute pas mal d'huile de coude, mais si tu regardes bien des tutoriels mingw-64, ça reste faisable, même si c'est bien plus compliqué que sous Linux.

Si tout cela te semble trop complexe pour un "coup d'oeil rapide", alors reste en 32 bits et penche toi plutôt sur l'optimisation de ta consmmation mémoire.

[freedom144]

Merci pour les informations je ne savais pas comment récupérer le GIT, sinon j'ai essayé de recompiler la GtlGlExt version 1.2 :
- configure pas de pb après modification pangox
- make erreur \bin\perl : bad : no found --- je cherche encore le pb.

Je vais tenter le GIT ou trouver une solution......

Sinon pour la mémoire je reste sur de moi , la solution pour le moment est de lancer un exe 64 bit à part. Car même en cas de fuites éventuelles j'utilise jusqu'a 25 "images" 2000x3000x3 en <double> plus 15 matrices <double> et <float>... sans compter l'ensemble de l'interface GTK et les affichages OpenGL.

[liberforce]

j'ai essayé de recompiler la GtlGlExt version 1.2 :
- configure pas de pb après modification pangox
- make erreur \bin\perl : bad : no found --- je cherche encore le pb.

bin à priori il ne trouve pas perl, mais normalement, il devrait le détecter lors du configure, pas du make.

Pour ce qui est de ta consommation mémoire, j'ai du mal à te suivre. Je ne vois pas ce que c'est que des images en "<double>". En RGB24 (3 canaux, chacun utilisant 1 octet par pixel), tes 25 images consomment 25x2000x3000x3 = 450 000 000 = 450 Mo.

Un double c'est 8 octets, et a priori tu n'as pas un double par canal R, G, et B, sinon tu te retrouverais déjà à 25x2000x3000x3x8 = 3 600 000 000 = 3,6 Go. Si c'est un double par pixel, c'est du RGBA64 (donc 4 canaux, et chacun utilisant 16 bits par pixel)
25x2000x3000x4x2 = 1 200 000 000 = 1,2 Go, m'enfin dans ce cas là, c'est plutôt géré comme un entier long 64 bits, pas comme un double il me semble. C'est ce format que tu utilises ? Est-ce que tu gères le canal alpha ?

L'interface GTK ne devrait pas consommer énormément de mémoire, une appli comme gedit ou devhelp, c'est entre 20 et 50 Mo. En openGL, cela dépendra de ce que tu dessines. Et pour tes matrices, ça dépend de leurs taille... A partir de cela, on peut effectivement estimer la consommation mémoire.

En revanche, je ne comprends pas pourquoi tu parles de saturation à 1,5Go. Il semble qu'un processus 32 bits peut monter à 2 Go, voire 3 ou 4 Go sur un système 64 bits.

[freedom144]

Pour ce qui est de ta consommation mémoire, j'ai du mal à te suivre. Je ne vois pas ce que c'est que des images en "<double>".

Un double c'est 8 octets, et a priori tu n'as pas un double par canal R, G, et B, sinon tu te retrouverais déjà à 25x2000x3000x3x8 = 3 600 000 000 = 3,6 Go.

Mes images ne sont pas des fichiers RGB commums, effectivement chaque pixel est un double. D’où mon problème de saturation avant même d'atteindre l'ouverture des 25 fichiers. Je fais de la sur-quantification d'images numériques, puis de la fusion.

En revanche, je ne comprends pas pourquoi tu parles de saturation à 1,5Go. Il semble qu'un processus 32 bits peut monter à 2 Go, voire 3 ou 4 Go sur un système 64 bits.

Je me suis déjà renseigné sur ce principe, apparemment il sert à augmenter la quantité de mémoire détecté par Windows 32bits mais il ne permet pas d'augmenter la quantité de mémoire allouée pour un processus tournant en 32bit sur un OS 64bits. Lorsque la quantité de RAM allouée pour un processus 32bit dépasse 1 500 000K voir 1 600 000K (verif dans le gestionnaire de tâche) on a le droit à une belle petite fenêtre de ce type : http://cavel.fr/xbmcBug/crashXBMC2.png

bin à priori il ne trouve pas perl, mais normalement, il devrait le détecter lors du configure, pas du make.

Effectivement aucun dossier /perl n'est présent :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
 
Alex@ROMULUS ~
$ cd /c/gtkglext
 
Alex@ROMULUS /c/gtkglext
$ ./configure
checking for a BSD-compatible install... /bin/install -c
checking whether build environment is sane... yes
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking build system type... i686-pc-mingw32
checking host system type... i686-pc-mingw32
checking for gcc... gcc
checking for C compiler default output file name... a.exe
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables... .exe
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking how to run the C preprocessor... gcc -E
checking for strerror in -lcposix... no
checking for a sed that does not truncate output... /bin/sed
checking for egrep... grep -E
checking for ld used by gcc... c:/mingw64/x86_64-w64-mingw32/bin/ld.exe
checking if the linker (c:/mingw64/x86_64-w64-mingw32/bin/ld.exe) is GNU ld... yes
checking for c:/mingw64/x86_64-w64-mingw32/bin/ld.exe option to reload object files... -r
checking for BSD-compatible nm... /mingw/bin/nm
checking whether ln -s works... yes
checking how to recognise dependent libraries... file_magic file format pei*-i386(.*architecture: i386)?
checking for dlltool... dlltool
checking for as... as
checking for objdump... objdump
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking dlfcn.h usability... no
checking dlfcn.h presence... no
checking for dlfcn.h... no
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking dependency style of g++... gcc3
checking how to run the C++ preprocessor... g++ -E
checking for g77... no
checking for f77... no
checking for xlf... no
checking for frt... no
checking for pgf77... no
checking for fort77... no
checking for fl32... no
checking for af77... no
checking for f90... no
checking for xlf90... no
checking for pgf90... no
checking for epcf90... no
checking for f95... no
checking for fort... no
checking for xlf95... no
checking for ifc... no
checking for efc... no
checking for pgf95... no
checking for lf95... no
checking for gfortran... no
checking whether we are using the GNU Fortran 77 compiler... no
checking whether  accepts -g... no
checking the maximum length of command line arguments... 8192
checking command to parse /mingw/bin/nm output from gcc object... ok
checking for objdir... .libs
checking for ar... ar
checking for ranlib... ranlib
checking for strip... strip
checking for correct ltmain.sh version... yes
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -DDLL_EXPORT
checking if gcc PIC flag -DDLL_EXPORT works... yes
checking if gcc static flag -static works... yes
checking if gcc supports -c -o file.o... yes
checking whether the gcc linker (c:/mingw64/x86_64-w64-mingw32/bin/ld.exe) supports shared libraries... yes
checking whether -lc should be explicitly linked in... yes
checking dynamic linker characteristics... Win32 ld.exe
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
configure: creating libtool
appending configuration tag "CXX" to libtool
checking for ld used by g++... c:/mingw64/x86_64-w64-mingw32/bin/ld.exe
checking if the linker (c:/mingw64/x86_64-w64-mingw32/bin/ld.exe) is GNU ld... yes
checking whether the g++ linker (c:/mingw64/x86_64-w64-mingw32/bin/ld.exe) supports shared libraries... yes
checking for g++ option to produce PIC... -DDLL_EXPORT
checking if g++ PIC flag -DDLL_EXPORT works... yes
checking if g++ static flag -static works... yes
checking if g++ supports -c -o file.o... yes
checking whether the g++ linker (c:/mingw64/x86_64-w64-mingw32/bin/ld.exe) supports shared libraries... yes
checking dynamic linker characteristics... Win32 ld.exe
checking how to hardcode library paths into programs... immediate
appending configuration tag "F77" to libtool
checking for some Win32 platform... yes
checking for native Win32... yes
checking for lib.exe... no
checking whether build environment is sane... yes
checking for gcc option to accept ANSI C... none needed
checking for a BSD-compatible install... /bin/install -c
checking whether make sets $(MAKE)... (cached) yes
checking whether ln -s works... yes
checking for gawk... (cached) gawk
checking how to get MSVC-compatible struct packing... -mms-bitfields
checking for perl5... no
checking for perl... no
checking for indent... no
checking for pkg-configx64... /c/GTKx64/bin/pkg-configx64
checking pkg-configx64 is at least version 0.9.0... yes
checking for BASE_DEPENDENCIES... yes
checking for pkg-configx64... /c/GTKx64/bin/pkg-configx64
checking for GLIB - version >= 2.0.0... yes (version 2.26.1)
checking for pkg-configx64... (cached) /c/GTKx64/bin/pkg-configx64
checking for GTK+ - version >= 2.0.0... yes (version 2.22.1)
checking for ANSI C header files... (cached) yes
checking for inttypes.h... (cached) yes
checking for stdlib.h... (cached) yes
checking for string.h... (cached) yes
checking for an ANSI C-conforming const... yes
checking for stdlib.h... (cached) yes
checking for GNU libc compatible malloc... yes
checking for memset... yes
checking for sqrt... yes
checking for strchr... yes
checking for strrchr... yes
checking for strstr... yes
checking gdk/gdkdisplay.h usability... yes
checking gdk/gdkdisplay.h presence... yes
checking for gdk/gdkdisplay.h... yes
checking gdk/gdkscreen.h usability... yes
checking gdk/gdkscreen.h presence... yes
checking for gdk/gdkscreen.h... yes
checking for gdk_display_get_default in GDK library... yes
configure: GDK supports multihead
checking GL/gl.h usability... yes
checking GL/gl.h presence... yes
checking for GL/gl.h... yes
checking GL/glu.h usability... yes
checking GL/glu.h presence... yes
checking for GL/glu.h... yes
checking for glNewList in -lopengl32... yes
checking for gluNewQuadric in -lglu32... yes
checking for GLhalfNV... no
Package pangox was not found in the pkg-config search path.
Perhaps you should add the directory containing `pangox.pc'
to the PKG_CONFIG_PATH environment variable
No package 'pangox' found
Package pangox was not found in the pkg-config search path.
Perhaps you should add the directory containing `pangox.pc'
to the PKG_CONFIG_PATH environment variable
No package 'pangox' found
Package pangox was not found in the pkg-config search path.
Perhaps you should add the directory containing `pangox.pc'
to the PKG_CONFIG_PATH environment variable
No package 'pangox' found
Package pangox was not found in the pkg-config search path.
Perhaps you should add the directory containing `pangox.pc'
to the PKG_CONFIG_PATH environment variable
No package 'pangox' found
Package pangox was not found in the pkg-config search path.
Perhaps you should add the directory containing `pangox.pc'
to the PKG_CONFIG_PATH environment variable
No package 'pangox' found
Package pangox was not found in the pkg-config search path.
Perhaps you should add the directory containing `pangox.pc'
to the PKG_CONFIG_PATH environment variable
No package 'pangox' found
configure: creating ./config.status
config.status: creating gdkglext.pc
config.status: creating gtkglext.pc
config.status: creating gdkglext-uninstalled.pc
config.status: creating gtkglext-uninstalled.pc
config.status: creating gtkglext.spec
config.status: creating gtkglext.nsi
config.status: creating Makefile
config.status: creating gdk/Makefile
config.status: creating gdk/gdkglversion.h
config.status: creating gdk/glext/Makefile
config.status: creating gdk/x11/Makefile
config.status: creating gdk/win32/Makefile
config.status: creating gtk/Makefile
config.status: creating gtk/gtkglversion.h
config.status: creating m4macros/Makefile
config.status: creating docs/Makefile
config.status: creating docs/reference/Makefile
config.status: creating docs/reference/gtkglext/Makefile
config.status: creating docs/reference/gtkglext/version.xml
config.status: creating examples/Makefile
config.status: creating examples/glade/Makefile
config.status: creating config.h
config.status: config.h is unchanged
config.status: executing depfiles commands
config.status: executing gdk/gdkglext-config.h commands
config.status: gdk/gdkglext-config.h is unchanged
 
configuration:
        OpenGL CFLAGS:          
        OpenGL LIBS:             -lglu32 -lopengl32
        multihead support:      yes
        debug:                  minimum
        extra defs:             
 
 
Alex@ROMULUS /c/gtkglext
$ make
make  all-recursive
make[1]: Entering directory `/c/gtkglext'
Making all in gdk
make[2]: Entering directory `/c/gtkglext/gdk'
make  all-recursive
make[3]: Entering directory `/c/gtkglext/gdk'
Making all in glext
make[4]: Entering directory `/c/gtkglext/gdk/glext'
make[4]: Nothing to be done for `all'.
make[4]: Leaving directory `/c/gtkglext/gdk/glext'
Making all in win32
make[4]: Entering directory `/c/gtkglext/gdk/win32'
make[4]: Nothing to be done for `all'.
make[4]: Leaving directory `/c/gtkglext/gdk/win32'
make[4]: Entering directory `/c/gtkglext/gdk'
cd .. && /bin/sh ./config.status gdk/gdkglext-config.h
config.status: executing gdk/gdkglext-config.h commands
config.status: gdk/gdkglext-config.h is unchanged
echo timestamp > stamp-gdkglext-config-h
( cd . && glib-mkenums \
                        --fhead "#ifndef __GDK_GL_ENUM_TYPES_H__\n#define __GDK_GL_ENUM_TYPES_H__\n\n#include <glib-object.h>\n\nG_BEGIN_DECLS\n" \
                        --fprod "/* enumerations from \"@filename@\" */\n" \
                        --vhead "GType @enum_name@_get_type (void);\n#define GDK_TYPE_@ENUMSHORT@ (@enum_name@_get_type())\n" \
                        --ftail "G_END_DECLS\n\n#endif /* __GDK_GL_ENUM_TYPES_H__ */" \
                gdkgl.h gdkgldefs.h gdkglversion.h gdkgltokens.h gdkgltypes.h gdkglinit.h gdkglquery.h gdkglconfig.h gdkglcontext.h gdkgldrawable.h gdkglpixmap.h gdkglwindow.h gdkglfont.h gdkglshapes.h gdkglglext.h ) >> xgen-geth \
        && (cmp -s xgen-geth ./gdkglenumtypes.h || cp xgen-geth ./gdkglenumtypes.h ) \
        && rm -f xgen-geth \
        && echo timestamp > stamp-gdkglenumtypes-h
/bin/sh: /c/GTK/bin/glib-mkenums: /bin/perl: bad interpreter: No such file or directory
make[4]: *** [stamp-gdkglenumtypes-h] Error 126
make[4]: Leaving directory `/c/gtkglext/gdk'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/c/gtkglext/gdk'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/c/gtkglext/gdk'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/c/gtkglext'
make: *** [all] Error 2
 
Alex@ROMULUS /c/gtkg

[liberforce]

Mes images ne sont pas des fichiers RGB commums, effectivement chaque pixel est un double. D’où mon problème de saturation avant même d'atteindre l'ouverture des 25 fichiers. Je fais de la sur-quantification d'images numériques, puis de la fusion.

Tu n'as pas vraiment répondu à ma question... RGB sur 32 bits, j'ai du mal à y croire...
Tu as combien de bits par canal, et combien de canaux (comprendre: est-ce que tu gères la transparence dans un 4ème canal, le canal alpha) ?

[quote=freedom144;7125663]
Je me suis déjà renseigné sur ce principe, apparemment il sert à augmenter la quantité de mémoire détecté par Windows 32bits mais il ne permet pas d'augmenter la quantité de mémoire allouée pour un processus tournant en 32bit sur un OS 64bits. Lorsque la quantité de RAM allouée pour un processus 32bit dépasse 1 500 000K voir 1 600 000K (verif dans le gestionnaire de tâche) on a le droit à une belle petite fenêtre de ce type : http://cavel.fr/xbmcBug/crashXBMC2.png

Relis le lien que je t'ai donné. Il parle explicitement d'applications 32 bits sur Windows 64 bits. Mais l'option de linker donnée semble être spécifique à la compilation sous Visual Studio...

Effectivement aucun dossier /perl n'est présent :

Logique, c'est à toi de l'installer. En revanche, il y a un bug dans le configure, il aurait dû s'arrêter pour te prévenir que perl était un pré-requis à la compilation.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
checking for perl5... no
checking for perl... no

Tu peux trouver perl pour Windows sur le site d'activestate il me semble.

En revanche, il y a autre chose qui me chagrine:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
checking build system type... i686-pc-mingw32
checking host system type... i686-pc-mingw32

Cela veut dire que ta config est détectée comme étant en 32 bits.
J'ai cherché un peu, et effectivement, on dirait que tu dois déclarer spécifiquement le type d'hôte pour compiler en 64 bits:
http://www.gaia-gis.it/spatialite-3....ow_to.html#env

Using the MinGW 64 cross-compiler is the same of using standard MinGW32: but in this case you are required to always specify the following ./configure argument:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
./configure --host=x86_64-w64-mingw32
make
make install

Mais est-ce que tu as bien téléchargé la dernière version de MinGW-64 ? La 2.0.7 ?:
http://sourceforge.net/projects/ming...w-w64-release/

Quelle est ta version actuelle de gcc ?

[freedom144]

Désolé pour cette réponse un peu tardive, mais je viens vous donner des nouvelles...

tous d'abord pour la version de MinGW W64 j'ai utilisé l'instal : tdm64-gcc-4.7.1-3 donc la version 4.7.

Pour ce qui est de la compilation ça à l'air d'avoir fonctionné, mais j'ai du déplacer un à un les fichiers de C:/gtkglext vers C:/GTKx64 enfin bon j'ai du louper une truc mais c'est pas grave je connais maintenant par cœur l'arboréscence de GTK ....

Les tests fonctionnes correctement pas de problème de link ou autre sous Code::blocks ...

Seul bémols, sous mon interface la fenêtre principale est segmentée en deux partie à gauche tout un lot de contrôle et à droite la partie graph OpenGL.
La partie de droite est une box (Hbox) dans laquelle je place mon Widget (gtk_drawing_area_new()); Hors petit problème lors de l'affichage la zone graph prend toute la fenêtre. En plein écran les contrôles sont visibles mais il ne répondent pas, en déplacent la fenêtre j'ai accès aux contrôles mais l'affichage se chevauche avec le graph ..... et si je clique sur le graph les contrôles disparaissent ...

Si quelqu'un à une idée ?? d’où cela peu venir sa me permettrait de gagner du temps, sinon je finirai bien par trouverai d’où cela peu venir.

PS: c'est la même interface en 32bits et aucun soucis de se coté la mais... mais il me semble que j'utilise la version 1.06 de gtkglext ...

PS2: encore un grand merci à liberforce pour ces conseils qui m’ont permis d'apprendre ...

[liberforce]

tous d'abord pour la version de MinGW W64 j'ai utilisé l'instal : tdm64-gcc-4.7.1-3 donc la version 4.7.

Je n'avais jamais entendu parler de cette version... Apparemment, TDM-GCC c'est un truc non officiel, non supporté par MinGW. Il ne faut pas non plus confondre la version de l'environnement et la version de GCC. TDM-GCC est le seul à utiliser la même numérotation, semble-t-il. Je te conseille les binaires officiels du projet MinGW-64, dont je t'ai donné les liens plus haut.

Seul bémols, sous mon interface la fenêtre principale est segmentée en deux partie à gauche tout un lot de contrôle et à droite la partie graph OpenGL.
La partie de droite est une box (Hbox) dans laquelle je place mon Widget (gtk_drawing_area_new()); Hors petit problème lors de l'affichage la zone graph prend toute la fenêtre. En plein écran les contrôles sont visibles mais il ne répondent pas, en déplacent la fenêtre j'ai accès aux contrôles mais l'affichage se chevauche avec le graph ..... et si je clique sur le graph les contrôles disparaissent ...

Sur les problèmes de placement, il faut en général vérifier les caractéristiques des conteneurs comme GtkHBox, et l'appel qui y ajoute le contenu. Les variables homogeneous, fill, expand. Voir les exemples sur:
http://developer.gnome.org/gtk-tutorial/2.90/x363.html

Ce n'est sans doute pas cela si tu dis ne pas avoir ce comportement en 32 bits, mais bon, on ne sait jamais...

[freedom144]

Je passe se sujet en résolu, car j'ai réussi à compiler et exécuter gtkglext en 64 bits grâce au conseil de liberforce.

En ce qui concerne le problème de placement du widget dans la fenêtre je n'ai pas réussi à résoudre le problème, ce n'est pas du aux caractéristiques des conteneurs.

J'ai vu sur le mailling list que je ne suis pas le seul ayant ce problème mais je n'ai pour le moment trouvé aucune solution.