Bonjour,
J'aurais voulu savoir s'il était possible de récupérer une image que j'affiche dans un JPANEL sans utiliser la classe ROBOT qui elle, fait un screenschot de l'écran.
Merci
Version imprimable
Bonjour,
J'aurais voulu savoir s'il était possible de récupérer une image que j'affiche dans un JPANEL sans utiliser la classe ROBOT qui elle, fait un screenschot de l'écran.
Merci
oui, tu peux en utilisant la méthode creatImage
:wink:Code:
2
PS: d'ailleur c'est la méthode de base pour les applis utilisant le double-buffering software
Mon problème c'est que mon panel n'est qu'une fênetre ouverte vers un objet image plus grand que ce que le panel ne peux m'afficher.
Donc en faisait monPanel.getWidth,... je n'aurai pas l'image en entier mais seulement ce qui est affiché, y'a-t'il une solution?
Le double-buffering est une technique d'affichage qui permet de fortement diminuer le clipping (scintillement de l'image lors des réaffichages fréquents). Le principe est, au lieu de dessiner directement dans un JPanel, on dessine en fait dans une zone mémoire (invisible a l'écran).
Lorsque l'on a fini de dessiner dans cette zone mémoire, on l'affiche véritablement à l'écran, en superposant les 2 images (l'ancienne qui est affichée et la nouvelle que l'on vient de manipuler)
ça a peut être l'air compliqué comme ça mais c'est hyper simple à implémenter dans un programme !!
Bout de code
http://java.developpez.com/faq/java/...oublebuffering
Exemple avec des applets
http://www.dgp.utoronto.ca/~mjmcguff/learn/java/07-backbuffer
:wink:
[Edité par Braim : Evitez les injures ;-)
Citation:
Envoyé par cyber_jad
bin récupère cet objet image là !
Je pense que je vais utiliser ta méthode du double buffering software.
En effet, mon application est la suivante. Je dois simuler un microscope virtuel en affichant des images JPEG2000 très grandes. Ce qu'il y'a c'est que mon décodeur jpeg2000 me décode les partie d'image que je désire mais par morceau (TILE). Pour le moment, j'affiche morceau par morceau en faisant comme si mon panel était une grille et je place le "morceau au bon endroit". L'image se construie ainsi petit à petit. Pour le moment j'utilise un vecteur qui possède toutes les image et je l'affiche. Le problème c'est quele panel est constament entrain de parcourir le vecteur et de repeindre le tout donc c'est pas très efficace. Je devrai également appliquer des filtres de couleur sur cette image affichée donc la solution est d'utiliser une image que je rafraichis dans le panel petit à petit comme dans le double buffering.
Si je me trompe dis le moi :D
Merci
Le DB ne va pas t'aider à diminuer la charge processeur ni améliorer les performances. Il va uniquement supprimer le clipping (image qui scintille et qui saute)Citation:
Envoyé par cyber_jad
Mais pour une appli comme la tienne je pense que c'est presque nécessaire de l'utiliser !
Tu peux peut-être essayer d'optimiser le code pour améliorer les perfs, genre ne réactualiser que ce qui s'affiche à l'écran, ...
:wink:
Quand tu parles de ne réactualiser que se qui s'affiche, tu veux dire utiliser la méthode g.drawImage en précisant un rectangle de réactualisation c ca?
oui tout à fait, en fait il faut essayer de réduire les temps de calcul si tu vois que ton prog rame (économiser les ressources).
est-ce que tu pense aussi à faire un Thread.sleep(xxx) dans ton thread d'affichage ? (afin de "calmer la bête" ?)
Tu veux dire que dans ma méthode PaintComponent(Graphics g), je dois mettre un Thread.sleep ????
non :lol: plutôt dans les boucles de tes méthodes run() :wink:Citation:
Envoyé par cyber_jad
Autre suggestion. Tu peux écrire une classe qui implémente l'interface java.awt.image.RenderedImage et mettre en place les fonctions de gestion des "tiles" ( getMinTileX(), getNumXTiles() etc. )
Tu laisses donc le runtime gérer les "tiles" à ta place.
Il faut que tu te plonges dans le fonctionnement des classes Raster, WritableRaster, DataBuffer, et ComponentColorModel. Inspire-toi de la classe BufferedImage mais surtout n'essaie pas de la dériver. ( un peu long à expliquer pourkoi ne pas le faire ).
Ca n'a rien de compliqué ( je l'ai fait ) et cela marche très bien. En plus, tu peux gérer ta mémoire comme tu le veux ( utiliser un pool de buffers pour les images affichées.)
Enfin, tu as directement accés aux composantes RVB d'un pixel, ce qui permet d'optimiser certains calculs ( histogramme par exemple).
Voilà.
A+
Hery
Un grand merci pour ton explication.
Est ce que cela t'ennuyerais de m'envoyer ton implémentation de la classe RenderedImage.
Et aussi m'expliquer ce que tu entend pas "utiliser un pool de buffers pour les images affichées"
Merci
Désolé, je ne peux pas t'envoyer le code de la classe( propriété industrielle ) et cela donnerait bcp d'indications sur le logiciel que ma société développe. Mais, franchement, cela n'a rien de compliqué.
Utiliser un pool de buffers : en fait, si tu écris toi même cette classe, tu connais l'espace mémoire que tu utilises pour ton image et quand tu as fini d'utiliser l'image, tu peux mettre "de côté" cet espace pour t'en reservir pour une autre image.
Avantage : Cela évite de faire des allocations dynamiques ( typiquement tu n'en fais qu'une au lancement ) ;
Inconvénient : Tu es obligé d'allouer un espace mémoire plus important que celui dont tu as réellement besoin.
Par exemple, si tu veux travailler sur des images 250x250 et 300x300, il faudra que tu alloues un espace mémoire de 300x300 même dans le cas 250x250.
Mais cela évite une outOfMemory et que le garbage collector se lance de manière intempestive.
Voilà
Bon courage.