notre probleme est de trouver un access a des references vers les instances des fentres donc l'api privé du window server, et là perso j'ai vu le coté obscure de l'api et une alternative tout aussi peu clair pour moi. (et l'inter app communication ?!)
en gros on ne peut que avoir aujourd'hui comme tout le monde ici le sait que les fenêtre de l' appli active (SuperMic).
bonsoir, après une semaine de relache je revient avec une nouvelle version. Vinc je n'inclut pas les modifs que tu fais pour etre sur d'avoir un truc que je controle, mais au final on pourra mettre ton bouton on/off ou tout autre chose. J'ai repris tes images et l'idée du dégradé au premier plan, juste j'ai ajouté une apparition/disparition. J'ai ajouté la gestion du Z suivant le numero de fenetre (voir le croquis au dessus). Corrigé ce problème de tête en bas.
Voilà c'est la version18, j'ai un peu nettoyé pour simplifier. Toujours des problèmes avec les reflets. Il faudrait que les fenetres n'aillent pas si bas...
J'espère que SuperMic pourra filer un coup de main ça serait dommage que ça reste en plan maintenant...
Oui, ok, j'avais bien compris que tu n'integrerais mes modules qu'à la fin
Trois questions : - Tu ne m'as toujours pas expliqué pourquoi tu utilises un iterator particulier pour le back aulieu de le traiter comme une simple fenêtre ? - En changeant le nombre de fenêtre via pomme+T de cette nouvelle version, ça donne l'impression que ça gère la position en profondeur en fonction du nombre de fenêtre ; l'idée que j'ai postée il y a quelques jours. Est-ce le cas ? parce que je ne le retrouve pas dans ton code... - Enfin, sur quoi es-tu en train de bosser ? Qu'améliore-tu ?
Bon, dans l'attente du retour de SuperMic... :why?:
- Tu ne m'as toujours pas expliqué pourquoi tu utilises un iterator particulier pour le back aulieu de le traiter comme une simple fenêtre ?
hum, ya pas de vrai raison; je pourrais la traiter comme un fenetre normale, si ce n'est qu'actuelemment elle a une animation bien différebte des autres.
dans 1133969846:
- En changeant le nombre de fenêtre via pomme+T de cette nouvelle version, ça donne l'impression que ça gère la position en profondeur en fonction du nombre de fenêtre ; l'idée que j'ai postée il y a quelques jours. Est-ce le cas ? parce que je ne le retrouve pas dans ton code...
oui bien sur c'est le cas, ça donne vraiment une impression de profondeur. Ca se situe dans le Macro patch Animation, il y a un patch "Z position variation", il a en entrée le nombre de fenetre et de la fenetre courante. Il divise l'espace en autant qu'il y a de fenetres, puis on le multiplie avec le numéro de la fenetre courante. Heu c'est comprehensible??
dans 1133969846:
- Enfin, sur quoi es-tu en train de bosser ? Qu'améliore-tu ?
en se moment rien, je bosse sur un autre truc (mais je trouve pas non plus de développeur pour m'aider), il faudrait que je fasse un site avec les compositions et autres macro pour QC que j'ai fait. J'ai un économiseur d'écran d'ailleurs. Enfin deux, j'en avais fais un pour macgé.
- En changeant le nombre de fenêtre via pomme+T de cette nouvelle version, ça donne l'impression que ça gère la position en profondeur en fonction du nombre de fenêtre ; l'idée que j'ai postée il y a quelques jours. Est-ce le cas ? parce que je ne le retrouve pas dans ton code...
oui bien sur c'est le cas, ça donne vraiment une impression de profondeur. Ca se situe dans le Macro patch Animation, il y a un patch "Z position variation", il a en entrée le nombre de fenetre et de la fenetre courante. Il divise l'espace en autant qu'il y a de fenetres, puis on le multiplie avec le numéro de la fenetre courante. Heu c'est comprehensible??
Oui oui, je vois. Et si j'ai bien compris, c'est un truc que t'as rajouté dans la v18. Et bien perso, je donnerai une profondeur un peu plus importante à se partager entre toutes ces fenêtre. Tant pis si la plus éloignée est un peu petite. Juste pour voir ce que ça donne.
en se moment rien, je bosse sur un autre truc (mais je trouve pas non plus de développeur pour m'aider), il faudrait que je fasse un site avec les compositions et autres macro pour QC que j'ai fait. J'ai un économiseur d'écran d'ailleurs. Enfin deux, j'en avais fais un pour macgé.
Je suis justement en train de réfléchir à faire un site pour notre économiseur. Ce serai plus simple peut-être, pour que les sites d'actu fassent une news sur le projet, pour que nous trouvions plus de développeurs.
Boris Cargo m'a parlé de ce projet et je le trouve interessant.
Alors, je vais essayer de vous aider un peu (même si j'ai pas trop de temps en ce moment...)
- Pour le "VincScreensaverIM.bundle", c'est simplement l'ajout d'une fonction "screenShotForAllWindows" à toutes les applications cocoa. Il faudrait pour l'utiliser faire une boucle sur toutes les applications ouverte et récupérer les .png dans le dossier : "~/Library/Caches/CapturerToutesLesFenetres/".
Bon, là , d'un, je suis aux anges parce que je vois que pt'êt que c'est parti pour la partie programmation ! et de deux, je vous laisse voir entres vous les gars pour ce qui est de... codes... charabia ! LOL
J'ai suivi 2 voies parallèles : - le window-warping qui permet la déformation des fenêtres en temps réèl (à l'image de ce que fait le Dock quand il miniaturise une fenêtre). - le window-grabbing qui permet de "prendre une photo" de n'importe qu'elle fenêtre.
Pour le window-warping, l'avantage est d'avoir des fenêtres déformées qui ont toujours leur contenu actualisé. L'inconvénient est de 2 ordres : il faut patcher le Dock afin d'être autorisé à modifier les fenêtre n'appartenant pas à notre appli (ce qui peut être source d'instabilité), et l'api Core Graphics qui permet de faire du warping est n'est pas encore stabilisé (mes exemples de code fonctionnent bien en 10.3, mal en 10.4). J'ai donc, pour le moment, mis de côté cette solution.
Pour le window-grabbing, c'est ok. En dumpant l'api Core Graphics, puis en faisant du debug, j'ai réussi à trouver la fonction Core Graphics qui permet la création d'une image de n'importe quelle fenêtre gérée par le window-server. Cette fonction est la même que celle utilisée par la combinaison de touche POMME+SHIFT+3, ou par l'appli Capture (dans les utilitaires), ou encore par la commande screencapture. Je pense donc que c'est assez stabilisé pour être utilisé.
Pour le window-grabbing c'est enorme ce que tu nous dis là ?!!! Et... comment comptes-tu relier ton travail au notres ? Est-ce que ça complete ou est ce que ça remplace les trouvailles de Supermic ?
Tu pourrais nous poster un exemple d'appli qui grab tout ça ?
Donc question à tous : comment on s'organise maintenant ? Qui fait quoi ? Je vous propose que chacun post son point de vue sur la suite des évenements, et ensuite on fait le point et on choisi une direction si elle va a tout le monde. Ca vous va ? Une conférence iChat serait la bienvenue peut-être ? On peut faire sans si ça embête certains.
Tu pourrais nous poster un exemple d'appli qui grab tout ça ?
Voilà !
L'appli en pièce jointe créé un fichier .png par fenêtre visible à l'écran. Les fichiers sont mis à la racine du disque dur, et le nom est "fenetre-XXX.png" où XXX est un numéro (le window-id) pour ceux qui connaissent).
Sur mon imac G5, avec une 40aine de fenêtres, ça met 22 secondes pour générer tous les .png.
Note : le fond de l'ecran est une fenêtre (la numéro 1), la barre de menu et chaque icône du finder sur le desktop sont aussi des fenêtres. Le Dock et les icônes dans le dock sont autant de fenêtres supplémentaires. Enfin, les UI-elements (les mini icônes dans la barre de menu à droite) sont aussi des fenêtres.
bon, en l'état, tu te doutes surement des question que je vais te poser :
- Est-ce que l'on peut ne récupérer que les "vraies" fenêtres ? (peut-être faut-il faire le tri en imposant une taille mini pour éliminer les barres de menu, dock, et icones ???) - Est-ce que dans ta méthode, on peut récupérer les coordonées des fenêtres récupérée ? (pour pouvoir les repositionner dans QC après) - Est-ce que l'on peut récupérer leur position en profondeur ? (savoir qui est au premier plan, puis second plan, etc... jusqu'au fond d'écran...) - Est-ce que l'on peut ne récupérer par exemple que les 5 premières, puis la dernière ? (tout ça avant d'écrire les fichiers sur le DD pour réduire le temps... et de sorte a ne récupérer que ce dont on a besoin : on sait que sur une machine lente, on ne va pas faire voler 50 fenêtre !)
Euh... voilà pour mes premières questions
Je précise bien que toutes mes questions sous-entendent qu'il serait a mon avis bon que tous les tri... etc... soient faits avant écriture sur le disque. Et j'y pense : sommes-nous obligé d'écrire tout ça sur le disque dans l'éco d'écran final ? Ou est-ce que ça peut juste être stocké en mémoire ? (plus rapide)
Mais... franchement : BRAVO !!! Génial ! Le projet avance ! Je suis comme un  :o ! MERCI !!!
PS : dernière petite question : Bru, tu te sentirais de pondre la partie programmation de cet économiseur d'écran ? En faisant le lien avec la partie QuartzComposer que essentiellement BorisCargo a développée ? Si quelqu'un veut bien t'aider : est-ce que c'est un truc sur lequel vous pourriez partager le boulot en deux ?
Non mais vraiement j'insiste ! C'est formidable ! Ca marche avec n'importe quel type de fenêtre ! Les contenus des fenêtre QuickTime sont là aussi ! Et MEME le contenu de la fenêtre du lecteur de DVD (DVD commercial ou non !).
BRA-VO ! Ca vaut bien un post juste pour dire à quel point je suis content !
- Est-ce que l'on peut ne récupérer que les "vraies" fenêtres ? (peut-être faut-il faire le tri en imposant une taille mini pour éliminer les barres de menu, dock, et icones ???)
Oui. Chaque fenêtre à un window-level qui permet de savoir quelle est sa catégorie (fenêtre standard, palette d'outil, barre de menu, menu, icône de finder, icône de dock, fond d'écran, etc...). Une simple sélection sur ce window-level permet de ne récupérer que les fenêtres "standards".
dans 1134210296:
- Est-ce que dans ta méthode, on peut récupérer les coordonées des fenêtres récupérée ? (pour pouvoir les repositionner dans QC après)
Re oui. On récupère position et taille.
dans 1134210296:
- Est-ce que l'on peut récupérer leur position en profondeur ? (savoir qui est au premier plan, puis second plan, etc... jusqu'au fond d'écran...)
Je ne sais pas encore. Pour récupérer la liste des fenêtres, j'utilise une fonction de l'AppKit NSWindowList. Il faudrait que je teste la position de chaque fenêtre dans la liste récupérée pour voir si elle correspond à la position de celle-ci en profondeur.
dans 1134210296:
- Est-ce que l'on peut ne récupérer par exemple que les 5 premières, puis la dernière ? (tout ça avant d'écrire les fichiers sur le DD pour réduire le temps... et de sorte a ne récupérer que ce dont on a besoin : on sait que sur une machine lente, on ne va pas faire voler 50 fenêtre !)
Je n'y vois pas de difficulté dès l'instant où on peut connaitre la position de chaque fenêtre en profondeur.
dans 1134210296:
Et j'y pense : sommes-nous obligé d'écrire tout ça sur le disque dans l'éco d'écran final ? Ou est-ce que ça peut juste être stocké en mémoire ? (plus rapide)
Non. La copie du contenu de chaque fenêtre est stockée dans un bloc mémoire (en fait dans une structure CGImage du Core Graphics). Pour la démonstration, c'est moi qui a fait en sorte d'écrire ces blocs mémoire sur disque au format png...
Non mais vraiement j'insiste ! C'est formidable ! Ca marche avec n'importe quel type de fenêtre ! Les contenus des fenêtre QuickTime sont là aussi ! Et MEME le contenu de la fenêtre du lecteur de DVD (DVD commercial ou non !).
De plus, j'utilise un contexte graphique ARVB pour récupérer le contenu des fenêtres. Le A de ARVB signifie Alpha : donc je récupère la couche de transparence (fais l'essai avec une fenêtre semi transparente...).
Sans rentrer dans les détails et juste pas curiosité, pourquoi c'est aussi lent ?
C'est la fonction d'écriture d'une CGImage dans un fichier qui est longue. La lenteur provient, à mon avis, de la conversion de la CGImage (qui est un bitmap non compressé en RVB avec Alpha) vers le format png.
Avec écriture sur disque : 22 sec... Sans écriture sur disque : 2 sec !
Que des bonnes nouvelles ! (en attendant celle de la profondeur... question promodiale dans le cas de cet économiseur d'écran)
Donc, vu que tu tiens à ton code (ce que je peux comprendre s'il est très spécial et que tu y a passé des heures et des heures ; c'est ton choix), comment envisages-tu la suite ? Ca veux dire qu'il n'y a que toi qui puisse finir le projet ? Ou est-ce que ça fonctionne par module ? As-tu du temps ?
Et... est-ce que tu pourrais nous tenir au courant de tes avancées... parce que j'étais loinde me douter que t'avancais dans ton coin sur le projet ! Petit cachotier ! Â ;)
Ok, j'en suis à : Tout est dans CoreFundation et ApplicationsServices (les 2 seuls frameworks associés à "Grab").
Il y a une classe NSClip... Apparement ils passent pas un service lookup (donc je suppose que via "Apple Event" on peut récupérer la liste des objets affichés par les applications ouvertes...) Enfin, il existe des fonctions sympa (CGContextCopyDisplayCaptureContentsToRect) utilisée par capture.
Bon je continue à chercher, mais j'ai l'impression d'être loin du but
Au fait pour la profondeur : "the order of windows in the array is the same as their order in the window server?s screen list (their front-to-back order on the screen)."
Enfin, il existe des fonctions sympa (CGContextCopyDisplayCaptureContentsToRect) utilisée par capture.
CGContextCopyDisplayCaptureContentsToRect est la fonction qui permet de copier l'écran en entier.
Si tu continue dans cette voie, tu n'es plus très loin... Ou alors tu attends que je publie les résultats de mes recherches ici même (dans Trucs et astuces) !
Réponses
MacOS X.4.3, 768 Mo de RAM
Carte ATI 32Mo (Quartz Extrême géré), écran 12" (1024x768)
Ca tourne à 20fps en plein écran. (et 60fps en mode fenêtre, si je modifie pas la taille qu'a la fenêtre du Viewer à l'ouverture du projet QC)
(Et oui, pour l'effet de "transition sèche" en effet c'est un problème de résolution d'écran
Ca fait une petite semaine qu'on a plus de nouvelles de Boris
Bon, aujourd'hui, je vais relancer SuperMic...il y a 15 jours, ilm'avait dit "a dans 15 jours !" alors...
Et puis je viens aussi de prendre connaissance de cet article http://highschoolblows.blogspot.com/2005/11/take-screenshot-of-dvd-player-in-os-x.html qui parle de l'utilitaire de capture en ligne de commande... si finalement il nous permettait de chopper le contenu de n'importe quelle fenêtre. Je ne sais pas.
A très vite à tous ! (Hey ? Boris : :why?:)
notre probleme est de trouver un access a des references vers les instances des fentres donc l'api privé du window server, et là perso j'ai vu le coté obscure de l'api et une alternative tout aussi peu clair pour moi. (et l'inter app communication ?!)
en gros on ne peut que avoir aujourd'hui comme tout le monde ici le sait que les fenêtre de l' appli active (SuperMic).
@+
Voilà c'est la version18, j'ai un peu nettoyé pour simplifier. Toujours des problèmes avec les reflets. Il faudrait que les fenetres n'aillent pas si bas...
J'espère que SuperMic pourra filer un coup de main ça serait dommage que ça reste en plan maintenant...
[Fichier joint supprimé par l'administrateur]
Chapeau.
Donc oui, une fois de plus bravo !
Oui, ok, j'avais bien compris que tu n'integrerais mes modules qu'à la fin
Trois questions :
- Tu ne m'as toujours pas expliqué pourquoi tu utilises un iterator particulier pour le back aulieu de le traiter comme une simple fenêtre ?
- En changeant le nombre de fenêtre via pomme+T de cette nouvelle version, ça donne l'impression que ça gère la position en profondeur en fonction du nombre de fenêtre ; l'idée que j'ai postée il y a quelques jours. Est-ce le cas ? parce que je ne le retrouve pas dans ton code...
- Enfin, sur quoi es-tu en train de bosser ? Qu'améliore-tu ?
Bon, dans l'attente du retour de SuperMic... :why?:
A très vite !
hum, ya pas de vrai raison; je pourrais la traiter comme un fenetre normale, si ce n'est qu'actuelemment elle a une animation bien différebte des autres.
oui bien sur c'est le cas, ça donne vraiment une impression de profondeur. Ca se situe dans le Macro patch Animation, il y a un patch "Z position variation", il a en entrée le nombre de fenetre et de la fenetre courante. Il divise l'espace en autant qu'il y a de fenetres, puis on le multiplie avec le numéro de la fenetre courante. Heu c'est comprehensible??
en se moment rien, je bosse sur un autre truc (mais je trouve pas non plus de développeur pour m'aider), il faudrait que je fasse un site avec les compositions et autres macro pour QC que j'ai fait. J'ai un économiseur d'écran d'ailleurs. Enfin deux, j'en avais fais un pour macgé.
Oui oui, je vois. Et si j'ai bien compris, c'est un truc que t'as rajouté dans la v18. Et bien perso, je donnerai une profondeur un peu plus importante à se partager entre toutes ces fenêtre. Tant pis si la plus éloignée est un peu petite. Juste pour voir ce que ça donne.
Je suis justement en train de réfléchir à faire un site pour notre économiseur. Ce serai plus simple peut-être, pour que les sites d'actu fassent une news sur le projet, pour que nous trouvions plus de développeurs.
Bon... SuperMic !!!!!!!!!?????? (ou d'autres !)
Boris Cargo m'a parlé de ce projet et je le trouve interessant.
Alors, je vais essayer de vous aider un peu (même si j'ai pas trop de temps en ce moment...)
- Pour le "VincScreensaverIM.bundle", c'est simplement l'ajout d'une fonction "screenShotForAllWindows" à toutes les applications cocoa.
Il faudrait pour l'utiliser faire une boucle sur toutes les applications ouverte et récupérer les .png dans le dossier : "~/Library/Caches/CapturerToutesLesFenetres/".
Par contre, je pense que ce code n'est pas necessaire.
En effet :
http://developer.apple.com/documentation/GraphicsImaging/Reference/Quartz_Services_Ref/index.html
Il semble qu'on peut avoir une liste des ID des "display" actifs :
Et donc récupérer un NSGraphicContext :
NSGraphicsContext *myGC = [NSGraphicsContext graphicsContextWithWindow: activeDspys];
Je n'ai aps eu le temps d'essayer par contre...
Mais ne récupère que les fenêtres du programme lui même...
C'est plutôt pour récupérer les écrans (physique) que les fenêtres...
:brule:
Moi, je n'ai jamais abandonné le projet...
J'ai suivi 2 voies parallèles :
- le window-warping qui permet la déformation des fenêtres en temps réèl (à l'image de ce que fait le Dock quand il miniaturise une fenêtre).
- le window-grabbing qui permet de "prendre une photo" de n'importe qu'elle fenêtre.
Pour le window-warping, l'avantage est d'avoir des fenêtres déformées qui ont toujours leur contenu actualisé. L'inconvénient est de 2 ordres : il faut patcher le Dock afin d'être autorisé à modifier les fenêtre n'appartenant pas à notre appli (ce qui peut être source d'instabilité), et l'api Core Graphics qui permet de faire du warping est n'est pas encore stabilisé (mes exemples de code fonctionnent bien en 10.3, mal en 10.4). J'ai donc, pour le moment, mis de côté cette solution.
Pour le window-grabbing, c'est ok. En dumpant l'api Core Graphics, puis en faisant du debug, j'ai réussi à trouver la fonction Core Graphics qui permet la création d'une image de n'importe quelle fenêtre gérée par le window-server. Cette fonction est la même que celle utilisée par la combinaison de touche POMME+SHIFT+3, ou par l'appli Capture (dans les utilitaires), ou encore par la commande screencapture. Je pense donc que c'est assez stabilisé pour être utilisé.
.
Tu pourrais nous poster un exemple d'appli qui grab tout ça ?
Donc question à tous : comment on s'organise maintenant ? Qui fait quoi ? Je vous propose que chacun post son point de vue sur la suite des évenements, et ensuite on fait le point et on choisi une direction si elle va a tout le monde. Ca vous va ? Une conférence iChat serait la bienvenue peut-être ? On peut faire sans si ça embête certains.
Dans l'attente,
Non.
Je fais ça immé.
.
Voilà !
L'appli en pièce jointe créé un fichier .png par fenêtre visible à l'écran. Les fichiers sont mis à la racine du disque dur, et le nom est "fenetre-XXX.png" où XXX est un numéro (le window-id) pour ceux qui connaissent).
Sur mon imac G5, avec une 40aine de fenêtres, ça met 22 secondes pour générer tous les .png.
Note : le fond de l'ecran est une fenêtre (la numéro 1), la barre de menu et chaque icône du finder sur le desktop sont aussi des fenêtres.
Le Dock et les icônes dans le dock sont autant de fenêtres supplémentaires.
Enfin, les UI-elements (les mini icônes dans la barre de menu à droite) sont aussi des fenêtres.
Bon test.
.
[Fichier joint supprimé par l'administrateur]
bon, en l'état, tu te doutes surement des question que je vais te poser :
- Est-ce que l'on peut ne récupérer que les "vraies" fenêtres ? (peut-être faut-il faire le tri en imposant une taille mini pour éliminer les barres de menu, dock, et icones ???)
- Est-ce que dans ta méthode, on peut récupérer les coordonées des fenêtres récupérée ? (pour pouvoir les repositionner dans QC après)
- Est-ce que l'on peut récupérer leur position en profondeur ? (savoir qui est au premier plan, puis second plan, etc... jusqu'au fond d'écran...)
- Est-ce que l'on peut ne récupérer par exemple que les 5 premières, puis la dernière ? (tout ça avant d'écrire les fichiers sur le DD pour réduire le temps... et de sorte a ne récupérer que ce dont on a besoin : on sait que sur une machine lente, on ne va pas faire voler 50 fenêtre !)
Euh... voilà pour mes premières questions
Je précise bien que toutes mes questions sous-entendent qu'il serait a mon avis bon que tous les tri... etc... soient faits avant écriture sur le disque.
Et j'y pense : sommes-nous obligé d'écrire tout ça sur le disque dans l'éco d'écran final ? Ou est-ce que ça peut juste être stocké en mémoire ? (plus rapide)
Mais... franchement : BRAVO !!! Génial ! Le projet avance ! Je suis comme un  :o ! MERCI !!!
PS : dernière petite question : Bru, tu te sentirais de pondre la partie programmation de cet économiseur d'écran ? En faisant le lien avec la partie QuartzComposer que essentiellement BorisCargo a développée ? Si quelqu'un veut bien t'aider : est-ce que c'est un truc sur lequel vous pourriez partager le boulot en deux ?
BRA-VO !
Sans rentrer dans les détails et juste pas curiosité, pourquoi c'est aussi lent ?
Des heures et des heures de gdb, nm, otool et shark, ça se paye...
hé hé hé
.
Oui. Chaque fenêtre à un window-level qui permet de savoir quelle est sa catégorie (fenêtre standard, palette d'outil, barre de menu, menu, icône de finder, icône de dock, fond d'écran, etc...). Une simple sélection sur ce window-level permet de ne récupérer que les fenêtres "standards".
Re oui. On récupère position et taille.
Je ne sais pas encore. Pour récupérer la liste des fenêtres, j'utilise une fonction de l'AppKit NSWindowList. Il faudrait que je teste la position de chaque fenêtre dans la liste récupérée pour voir si elle correspond à la position de celle-ci en profondeur.
Je n'y vois pas de difficulté dès l'instant où on peut connaitre la position de chaque fenêtre en profondeur.
Non. La copie du contenu de chaque fenêtre est stockée dans un bloc mémoire (en fait dans une structure CGImage du Core Graphics). Pour la démonstration, c'est moi qui a fait en sorte d'écrire ces blocs mémoire sur disque au format png...
.
De plus, j'utilise un contexte graphique ARVB pour récupérer le contenu des fenêtres.
Le A de ARVB signifie Alpha : donc je récupère la couche de transparence (fais l'essai avec une fenêtre semi transparente...).
.
C'est la fonction d'écriture d'une CGImage dans un fichier qui est longue.
La lenteur provient, à mon avis, de la conversion de la CGImage (qui est un bitmap non compressé en RVB avec Alpha) vers le format png.
Avec écriture sur disque : 22 sec...
Sans écriture sur disque : 2 sec !
.
Donc, vu que tu tiens à ton code (ce que je peux comprendre s'il est très spécial et que tu y a passé des heures et des heures ; c'est ton choix), comment envisages-tu la suite ? Ca veux dire qu'il n'y a que toi qui puisse finir le projet ? Ou est-ce que ça fonctionne par module ? As-tu du temps ?
Et... est-ce que tu pourrais nous tenir au courant de tes avancées... parce que j'étais loinde me douter que t'avancais dans ton coin sur le projet ! Petit cachotier ! Â ;)
Tout est dans CoreFundation et ApplicationsServices (les 2 seuls frameworks associés à "Grab").
Il y a une classe NSClip...
Apparement ils passent pas un service lookup (donc je suppose que via "Apple Event" on peut récupérer la liste des objets affichés par les applications ouvertes...)
Enfin, il existe des fonctions sympa (CGContextCopyDisplayCaptureContentsToRect) utilisée par capture.
Bon je continue à chercher, mais j'ai l'impression d'être loin du but
Au fait pour la profondeur :
"the order of windows in the array is the same as their order in the window server?s screen list (their front-to-back order on the screen)."
CGContextCopyDisplayCaptureContentsToRect est la fonction qui permet de copier l'écran en entier.
Si tu continue dans cette voie, tu n'es plus très loin...
Ou alors tu attends que je publie les résultats de mes recherches ici même (dans Trucs et astuces) !
.
G5 Bi 2.5, 2 Go RAM, Os X 10.4.2, 2 écrans, ....
[Fichier joint supprimé par l'administrateur]