Je voulais savoir si il existe (et comment les recuperer) un equivalent aux Handle et autres HDC de composant graphiques ....
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Handle, HDC and friends
Je voulais savoir si il existe (et comment les recuperer) un equivalent aux Handle et autres HDC de composant graphiques ....
En version plus simple, quel comportement cherches tu à réaliser pour tes composants? (Désolé l'API win32 et moi ça fait 2)
Ca tombe bien, c'est pas de l'API Win32 dont j'ai besoin ... ca c'est mon domaine(Désolé l'API win32 et moi ça fait 2)
Donc clairement je cherche a acceder au "handle" d'une form pour y dessiner dessus.
Le but (un peu fou) serais de transmettre cette valeur a une dll c++ (ou delphi dans un premier temps) qui s'en servirais pour initialiser un moteur 3D et y effectuer un rendu. A cours terme j'envisage de piloter une librairie 3D basé sur directX actuel depuis un programme java au travers d'une dll delphi. A plus long terme la dll sera recode en C++ et apres coup deplacé vers une API OpenGL pour maintenir une compatibilite Windows/Linux voir meme Mac.
C'est ce que j'appelle une migration "en douceur"
Ce projet peut etre fou .... mais, meme dans le cas ou il est irrealisable ou simplement inexploitable, j'aurais eu au moins l'occasion de soulever suffisement de problemes techniques pour posseder une bonne connaissance generale du langage.
quitte a apprendre un nouveau langage java, autant aller a l'essentiel et taquiner ses entrailles
Les tutos "HelloWorld" c'est pas mon truc :p
Bah j'ai bien peur que tu doives bouffer du JNI dans tous les sens dans ce cas. Car java et l'interaction avec l'OS hôte ne sont en général pas e grands potes.
Donc en ce qui concerne la logique de ton appli ça peut être réalisé coté java, mais ensuite en ce qui concerne la communication avec l'OS tu devras plus que probablement écrire ça en C++ et/ou Delphi.
Pour te faire une idée de ce qu'est JNI: http://www.javaworld.com/javaworld/j...ni.html?page=1
Ainsi que le tuto de Sun:
http://java.sun.com/developer/online...CBook/jni.html
Ce ne sont pas de simples helloworld, même s'il est sur qu'ils ne vont peut être pas aux bas fonds du bestiau.
Penses également à regarder les ressources présentes en base des 6 pages
Mais bon avec tout ça ce que tu feras en java pur devrait être relativement simple et le gros du travail sera réalisé en C++ ou delphi
Une autre alternative serait d'attaquer directement OpenGL en java avec JOGL (bindings java/OpenGL) ou des surcouches comme JMonkeyEngine
En fait non .... je ne pense pas autant que ca.Envoyé par sinok
Sous un systeme win32 il me suffit juste du handle de l'objet qui sert de zone de rendu.
Donc en gros, la seule info que j'ai a transmettre de Java vers la dll est cette "form".
Bon apres j'ai quelques apis de pilotages pour connecter le GUI java a ma Dll (load object, load file, etc ...) le classique quoi.
Ca reste des string, des int, des trucs pas tres complexe.
C'ets prevu. Java ne s'occupe que du GUI.
Meme si c'ets de l'interpreté, je suppose que les objets graphique se repose sur des objets systeme non ? c'ets pas du "TOUT" interprété ?
Je suppose que la jvm sert de wrapper entre le systeme et les byte code java ?
Donc l'objet graphique devrait avoir une existance propre aupres du systeme .. donc quelque part un handle ... non ?
Oui je viens de voir 2, 3 sites et fait des tests. Je comprends pas trop mal le systme de base ...
facon de parler
Disons que je ne suis pas du genre a me frapper les tutos de base exercices par exercices ... mais plutot partir sur un projet et chercher les infos dont j'ai besoin au fil du code. Quite a ce que ce soit la gestion des stream, ou autres truc assez complexe.
Oui, toute la partie gestion 3D. d'ailleur question perfs ca devrai etre prefereable non ?
bien ! je vais voir ca
Par contre je suis une quiche en 3D ... c'est mon taff qui veux ca
Donc si possible j'aimerais des libs un peu complete, genre "Mesh.LoadFile" et non comme je l'ai vu sur certains tutos OpenGL : creer son fichier et charger son mesh point par point, face par faces ..... :'(
Plus des trucs galeres comme le rendu des ombres, la transparence, etc ....
Bon en fouillant un peu j'ai trouvé quelquechose qui ressemble à ce que tu cheches, en passant par JNI et JAWT
http://www.javaworld.com/javaworld/j...javatip86.html
http://java.sun.com/j2se/1.5.0/docs/...Interface.html
Par conter ça a l'air relativement limité. Enfin à voir.
Sinon niveau 3D en java pur tu gagneras en simplicité à passer par un Scénographe comme JMonkeyEngine. Ensuite je ne suis pas expert en la question.
En ce qui concerne les perfs, tout dépend du coût de la tâche que ntu as à réaliser, si tu es sur d'avoir un gain de perf appréciable avec JNI, dans ce cas vas y, si le gain de perf est minimal autant éviter de se faire ch*** pour rien car JNI peut être un peu touchy par moments, en particulier vis à vis du GarbageCollector.
A toi de voir ensuite.
Mais je ne comprends toujours pas pourquoi il te faut absolument le Handle de ta fenêtre java, car tous les processus de communication et de threading peuvent se faire à travers JNI. A moins de vouloir dessiner directement sur ta fenêtre java...
C'ets le butA moins de vouloir dessiner directement sur ta fenêtre java...
En fait le moteur 3D a besoin du handle de la fenetre de rendu pour y dessiner le rendu de la 3D. Il utilise surement un systeme du genre "dessins sur une image" puis "copie de l'image sur le canvas de la fenetre" en passant par les API windows de traiement de l'image ....
Je vais voir tes liens.
Je regarderais aussi JMonkey .... mais niveau 3D il me faut quand meme quelque chose d'assez complet. Pour info en openGL Ogre est assez connu et correspond a nos attentes ...
Mais necessite c++ D'ou mon interet pour les JNI
Bonjour,
je ne sais pas si ce que je vais poster a une relation avec le sujet traité dans ce topic (je ne connais pas grand chose en 3D ) mais je poste quand même:
Connais-tu JOGL qui repose entièrement sur OpenGL et qui est exploitable en Java ?
désolé si ce post n'est pas à sa place
@+
oui j'ai lu ca sur un post precedent.
Si JOGL n'est qu'un wrapper sur les API OpenGL ca ne m'interesse pas trop car il me semble que l'on ne peut pas importer directement sous openGL des objets complxes, et qu'il fautr passer par un analyseur de fichiers 3DS, etc .. et assembler l'objet vertex par vertex et facettes par facettes ... trop complexe.
DE plus j'aurais aime utiliser le moteur actuel que je maitrise tant bien que mal
Par contre c'est plus limitant qu'auter chose ce moteur. Tu es sur de ne pas pouvoir récupérer les rendus sous forme d'image (et don potentiellement de tableau de bytes). Car là tu vas êter salement limité au niveau des composants java (mélanger Swing et AWT n'est en général pas la meilleure chose à faire)
heuuu oui .... je dois pouvoir faire ca.
Mais je me pose une question : comment java gere t il le graphisme ? Il fait tout lui tout seul ? ou bien il se base sur les API systeme ?
Sous delphi, les objets graphiques sont quand meme basé sur les API windows et damande au systeme d'afficher et de gerer ces objets.
Au niveau ed java, le fait que ce soit un systeme interprété, je ne vois pas comment il reagit ? Tot ou tard, il faut bien que le runtime java fasse appel aux api du systeme .... donc a mon avis, creer une "fenetre" (window) au sens windows du terme (et non composant type "form") donc ... possedant un handle ...
De la meme maniere, parmis les API windows, il existe des fonction du type getWindowsAtPos(x, y) retournant le handle de la fenetre au coordonnés ecran x, y, qui nous permet au travers d'autres api de la piloter, lui envoyer des messages, etc ...
On peut ainsi "piloter" une application a partir d'une autre, independament des langages de developpement.
Ce phenomene est il possibe avec Java ? ou bien en fait, le runtime est l'application elle meme et qui en interne fait ce qu'elle veux ?
Si le runtime ne fait que "convertir" le byte code en instruction assembleur du systeme (ie une sorte de convertisseur class/exe) dans ce cas, les JPanel et autres doivent posseder un handle ... encore fau til que java nous permettent d'y acceder .....
En fait java procède de la même façon que .NET en ce qui concerne la compilation.
Ensuite au niveau graphique Swing se base sur Java2D come api. Cette API elle va utiliser GDI et DirectX pour dessiner sur une fenêtre windows. Il faut voire que swing réalise tout le dessin en interne alors que AWT utilises les composants de l'OS.
Et plus j'y repense, plus je te verrais utiliser une lib plus proche de l'OS en ce qui concerneles graphismes: SWT.
Mais là je ne connais pas trop.
Et puis faire joujou avec les handle, je sais pas car en portant ton appli sous X11 tu risques d'en baver car tu pars sur un point de vue de conception très "Windowsien"
Alors que le passage du tableau de bytes est quelquechose qui ne varieras pas d'un OS à l'autre
Désolé .. mais je suis encore plus alergique a .Net que je ne l'etais a java
Au moins java est multiplateform
Je ne connait donc pas plus .Net que Java. Le seul repere en modele interprete que je connaisse c'est "BPC" (BestPascalCompiler) mon compilo pascal issu d'un projet de fac
Justement ... GDI et DirectX sont base sur la manipulation de handle ....
J'y connait pas grand chose, mais le peut que j'ai touche reviens a ca.
Connait pas, je vai svoir ca.
Sinon il me semble avoir lu quelque part que l'on pouvais developper avec GTK .... ca peut etre une solution non ? ou QT Peut etre ....
Oui bien sur !
En fait le handle j'en ai besoin que pour initialiser un moteur 3D qui de toute maniere est dedie a Windows (a bse DirectX)
Mais ce post pour but de commencer le developpeur de l'application autour de la gestion 3D, independement du systeme. .... C'ets toujours ca de gagné.
Oui, je vais voir ca de plus pres.
En fait il suffirais que je recupere l'image dessinée et que je l'affecte au tableau de byte d'un composant type image recupéré par JNI ?
J'ai quand meme peur que ca soit un poil long (perte de perfs) et surtout d'effecter le rendu ailleur que sur une form ...
Eventuellement fait le rendu sur un composant windows offscreen, en récupérer l'image et la passer à java. Comme ça tu restes avec un niveau d'abstraction relativement correct (la partie JNI ne traite que des tableaux de bytes).
Sinon en ce qui concerne la compilation java procède à de la compilation dite Just In Time qui va compiler le bytecode en natif la prmière fois que la classe est utilisée. Le fois siuvantes, la classe est déja présente en natif, donc plus de recompilation nécessaire du ByteCode. Donc en fait java n'est pas réellement un langage interprété. (Sinon ça serait largement plus lent que ça ne l'est)
Quand tu parle "offscreen" c'est au dela de la resolution ecran ?
C'est bourrin .... puis j'ai peur que le rendu ne soit pas effectif. J'ai remarquer certains phenomenes qui me laisse peut d'espoir.
Justement. Donc les objets graphiques doivent avoir un handle ....
Je vais faire des tests en tentant de recuperer les handles des objets java a partir d'un applciation delphi via les api Win32.
Si j'arrive a piloter ainsi uen frame ... ya peut etre un moyen de detecter depuis la dll le handle de la fenetre de rendu dynamiquement a l'execution ....
Pourtant le rendu offscreen (c'est à dire que le composant n'est pas visible) sur les composants des OS est une technique relativement connue. Elle est employée particulièrement pour les Look & Feels natifs en java (comment faire pour qu'un appli Swing ait un Look Windows ou GTK selon l'OS hôte). QT effectue la même opération afin d'offrir un rendu windows (enfin donner à ses widgets l'apparence de windows).
Ha. Ca je ne connaissait pas.
Je vais voir ca au cas ou ....
Je sous ouvert a toutes solutions ... surtout si elle sme font apprendre des nouveaux trucs.
Répondre avec citation
Partager