De GTK+ 32bit vers GTK x64

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..?... :cry:

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.

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.

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...

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.

Citation:

---

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 .... :cry:

Citation:

---

Envoyé par freedom144

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.

Citation:

---

Envoyé par freedom144

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

---

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:

---

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:

---

cd gtkglext

---

Puis basculer sur la branche master:

Code:

---

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.

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.

Citation:

---

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.

Citation:

---

Envoyé par liberforce

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>".

---

Citation:

---

Envoyé par liberforce

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.

Citation:

---

Envoyé par liberforce

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

Citation:

---

Envoyé par liberforce

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:

---

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

---

Citation:

---

Envoyé par freedom144

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...

Citation:

---

Envoyé par freedom144

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:

---

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:

---

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

Citation:

---

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:

---

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 ?

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 .... :lol:

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

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 ...

Citation:

---

Envoyé par freedom144

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.

Citation:

---

Envoyé par freedom144

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...

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.