Juste pour signaler un bug avec Interface Builder. Une view sélectionnée est prise en compte comme une fenêtre, et ça produit un cadre transparent qui se ballade. :P Voici le grab de la fenêtre (qui elle est bien prise en compte) et de la view sélectionnée à l'intérieur.
Ce n'est pas un bug...
IB utilise une fenêtre-fille transparente de même "niveau" qu'une fenêtre document pour afficher le cadre de sélection (mais aussi divers autres éléments).
D'un point de vue système, c'est donc une fenêtre comme les autres.
Par contre, ça illustre le soucis des fenêtre filles (comme les sheets ou drawers) : en effet, actuellement, je n'arrive pas à récupérer l'info comme quoi la fenêtre est une fille, ni qu'elle est sa mère. Si je le savais, cela permettrait de recomposer une seule image de fenêtre en ré-assemblant la mère et ses filles.
Ah au fait pour info (et pour pseudo-répondre au 1er commentaire qui a été fait sur VersionTracker), depuis que je suis revenu chez moi et installé la dernière version sur mon iMac Intel, le bug qui l'empêchait de se mettre en suspension d'activité a disparu. Donc le gars qui a posté le 1er commentaire sur VT soit avait testé une version précédente, soit a rerévélé dans une autre configuration, mais en tout cas chez moi ça le fait plus.
- désactivation de la mise en veille de l'écran (à tester). Par contre la mise en veille système reste active.
Mais, quelques posts plus loin, on pouvait lire dans ce message :
Autre bug mais dont je ne suis pas sûr (j'ai pas fait de tests intensifs sur ce dernier), j'ai l'impression que mon Mac ne suspend plus son activité tout seul quand il y a cet économiseur d'écran. Fenêtres Volantes peut tourner ainsi pendant longtemps sans que mon écran ne passe au noir (ça je crois que c'est fait exprès ?) ni même qu'il se suspend et se mette "à respirer au ralenti".
Donc, j'ai supprimé cette désactivation, comme relaté dans ce post :
Le seul bug évoqué est celui de la non mise en veille. Apparemment, le blocage de la mise en veille de l'écran bloque aussi la mise en veille système sur certaines machines. Donc, je supprime ça. A charge pour l'utilisateur de régler dans son panneau Economie d'énergie les valeurs s'il veut jouir de Fenêtres volantes plus longtemps.
Oui oui je sais bien j'avais suivi. Je sais que tu avais désactivé la suspension d'activité de l'écran. Et je t'avais relaté que chez moi mon iMac ne se mettais pas en veille (suspension activité du mac).
Evidemment il y avait 99% de chances que ce soit lié, c'était limite une évidence. Mais fallait bien que je confirme que depuis que tu as enlevé ce truc pour empêcher la suspension de l'écran, le bug inhérent (le fait que ça empêchait *aussi* la suspension du mac) a du coup disparu.
Ca semblait évident, mais bon, j'ai déjà rencontré des bugs où j'étais sûr de savoir doù ça venait et en fait m'étais totalement gourré, alors fallait bien que je confirme, on ne peut fermer un bug qu'après avoir passé la phase de test validant qu'il n'apparaà®t plus du moins dans les conditions où avant il apparaissait.
je sais que cela a peu de chose avec les tests que vous faites actuellement et que mars 2007 est trés loin, mais avez vous vu la video sur le core animation?
C'est peut être de nouvelles perpectives pour l'économiseur. en tout cas je suis assez bluffé(mais plus encore par la "time machine")
Bon, la prochaine release ne fera pas que (essayer de) corriger le bug du SC blanc.
Ca m'a pris 3 heures hier, mais j'ai pu une fois de plus hacker le window-server : maintenant, je peux savoir si une fenêtre est fille (donc attachée à une fenêtre mère), et je peux savoir qui est la mère. Donc, grande conséquence : les drawers, sheets et autres trucs bizarres à la IB (cf le post d'Eddy) seront envoyés au module .qtz dans la même image que leur mère.
De plus, si à la WWDC, et suite à l'implantation des multiples bureaux dans le 10.5, je vais essayer d'anticiper çà en n'envoyant au module .qtz que les fenêtres appartenant au bureau affiché.
Salut, bon voilà les vacances sont finies... En allant à droite à gauche j'ai pu voir que dans l'ensemble les gens étaient plutot satisfait. Voir impressionné. ::) Reste le problème des perfs. Certains se plaignent de surchauffe, des ventilos qui turbinent des ressources bouffés et j'en passe. Quartz composer tire partie du GPU, alors bien sur avec un carte video vieille ou pas performante il est difficile de profiter de l'accélération graphique des cartes. A titre info un mac mini G4 a 32M de mémoire vidéo, sur le macmini intel ya même plus de mémoire video, elle est partagée avec la ram (il me semble) alors les perfs sont pas terribles c'est vrai, mais je suis pas sur qu'en programmant le tout diretc en OGL on gagne beaucoup.
Il faudrait faire un calcul rapide pour voir combien de Vram est bouffé par les textures qui sont envoyées à la carte. Chez moi j'ai une résolution de 1080x1024, alors rien que ça, ça fait une texture de 5M, plus la mémoire pour l'affichage on arrive à 10M, on doit arriver facilement à dépasser 32M. Je pense que sur des petites configs il faudrait envoyer des texures en quart de définition.
Cool ! T'es revenu ! Alors ? C'est pas énorme tout ça ? Ca plait vachement notre petit truc ! Hein ?
Bon... oui, effectivement, il y a quelques plainte de vitesse et de charge processeur. Cela dit, ça va s'estomper très rapidement ces remarques... Plus ça va, plus les machines seront capables de le faire fonctionner sans surcharge (grace à un repport de 100% sur le GPU). Quant à la solution de baisser la résolution, j'en suis pas fan dutout : l'effet des fenêtres qui se décollent risquerai d'être cassé puisque d'un coup tout deviendrai flou/moche. Donc tu confirme qu'un développement en OpenGL directement ne ferai pas tant gagner que ça. Bon. C'est bien ce que je me disais.
Perso, j'ai reçu beaucoup de demande de gens qui ont des grosses config, et qui auraient souhaité pouvoir activer les deux anti aliasing possible (celui interne au fenêtre, et celui des bords des fenêtres).
Evidement, l'autre demande serait que le contenu soit mis à jour. Et là , c'est une question à Bru pour quand il reviendra : est-ce que l'on ne pourrait pas mettre à jour le contenu toutes les 20 secondes ? (enfin je sais même pas si ce serait une bonne idée...)
Enfin, une troisième grosse demande, c'est que le bureau reste plein de son contenu et de la barre des menus... est-ce que Bru, t'arriverai à "recréer" l'image du bureau complet à partir de tous ses éléments ? (sachant que maintenant, tu sais trouver les éléments "fils" et "Parents")
Mais quoi qu'il en soit, pour l'instant, focalisons-nous sur une version débuggée. Avant tout. Après, si dans cette version débuggée, on y ajoute une fonction "Bonus"... ça permettrai de relancer buzz autour de notre "bébé"
Une petite précision, je pense que ça serait pas plus rapide direct en OGL, mais j'en suis pas sur à 100%. Faudrait voir un spécialiste.
J'ai fait un peu joujou avec OpenGL il y a 2 ans, et en effet, comme il y a peu d'objets (de triangles), le gros du travail est de plaquer les textures, tâche qui revient au processeur graphique. Bref, il est peu probable de gagner en vitesse. Il est préférable que toutes les textures soient mises dans la RAM vidéo pour des questions de performances. Mais pas obligatoire, il me semble en OpenGL.
Une astuce: le fond d'écran est à environ 1/4 de sa taille d'origine une fois au fond. Peut-être pourriez vous diviser par 2 ses dimensions avant de la mettre en VRAM. Je pense que la dégradation serait peu visible.
Ben je commence à me demander si on pourrait pas faire un menu simple pour l'utilisateur, du genre "Rendu : Haute qualité / Normal / Basse qualité", et qui, en toile de fond, fasse :
Haute qualité - Gourmand en ressources : - Active les anti-aliasing possibles
Normal (par défaut): - Comme actuellement
Basse qualité - Economique en ressources : - Réduise l'ensemble des textures par 2 (mais gagnera-t-on réellement en fps ? ou en % d'occupation processeur ?) - Réduise le fps à 30fps (est-ce techniquement possible avec QC ?)
Qu'en dites-vous Bru et Boris ? J'envisage ça pour la prochaine beta en fait. Ce qui donnera comme nouvelles fonctionnalités : - antialising (une très grosse demande dans les feed-back) - Fenêtres filles attachées aux mères (que Bru à déka implémenté je crois) Ca me paraà®t être un bon objectif pour cette version 1.
J'ai une mauvaise nouvelle. Le bug de l'écran blanc est un bug de Quartz Composer. Et je n'ai aucun moyen de le contourner. Donc, je ne pourrais rien faire de ce côté.
Par contre, je pense au futur (notamment, la mise à jour du contenu des fenêtres). Et là , le plus simple est d'abandonner Quartz Composer, et de jouer directement avec le window-warping.
Le window-warping est la possibilité d'appliquer aux fenêtres une matrice de déformation. J'ai enfin terminé de désassembler la fonction qui permet celà , et je commence à maà®triser les déformations.
J'en reparlerai à mon retour de vacances (à la "rentrée").
C'est sur que tout programmer toi même t'apporteras plus de souplesse et de possibilité pour l'avenir. A toi de voir au mieux.
La fonction de recopie d'écran (et de fenêtre) est gourmande en temps. Les essais que j'ai réalisé pour mettre à jour le contenu des fenêtres (j'avais réglé le délai de mise à jour à 10 secondes) ont montré des performances catastrophiques.
Pendant chaque mise à jour d'une seul fenêtre, l'animation QC se fige, puis reprend avec une espèce de "bond". Je ne sais pas si tu peux maà®triser ça dans le module.
Concernant le window-warping : il faut créer des matrices de déformations pour pouvoir les appliquer par la suite aux fenêtres. Cela dépasse mes compétences. Quiconque est intéressé par ça est le bienvenu ! Donc, non, je ne programmerai pas tout par moi-même.
Pour expliquer les possibilités du window-warping, tu peux faire un test : ouvre une fenêtre du terminal, et tape la commande suivante sans l'exécuter : [tt]killall Dock[/tt] Ensuite choisis une fenêtre (si possible la plus grande, et pourquoi, une fenêtre animée -genre un quicktime, ou une pag web- ). Miniaturise cette fenêtre tout en pressant la touche SHIFT : la fenêtre est aspirée par le Dock très lentement. Très vite (sans lacher SHIFT) retourne dans le terminal et valide ta commande (en tapant RETURN). Tu verras alors ta fenêtre se figer dans sa déformation. Et surtout, tu peux voir cette fenêtre pleinement fonctionnelle (tu peux la déplacer si tu arrives à choper la barre de titre), et surtout, son contenu est vivant.
Bon, déjà , pour la mauvaise nouvelle (que l'écran blanc vienne d'un bug de QC) : Ca veut dire que t'as réussi à le faire reproduire chez quelqu'un de concerné, avec un autre module QC tout simple placé à la place de notre module ? Si c'est le cas : bon, il ne reste plus qu'à le préciser dans les bugs connus lors de la sortie de la prochaine version.
A part ça, comment envisage-tu l'avenir pour la version 1 Bru ?
D'autre part, j'ai fait joujou avec la commande killall Dock : Effectivement, avec tout un tas de logiciels, ça marche impec' : c'est très impressionnant !!! Je suppose que tu envisage donc de travailler là dessus pour la version 2 ? Mais : - Qu'entends-tu par "matrice de déformation" ? C'est des sortes de mouvement type ? - Penses-tu que CoreAnimation puisse être utilisé comme matrice de déformation ? (bien que je trouve que cela rendrai la version 2 éllitiste à ceux qui ont léopard exclusivement...) - As-tu des pistes ou des contacts de gens qui connaissent et savent utiliser ces matrice de déformation ?
C'est clair que c'est très très prometteur. Que les contenus changent en temps réel est la deuxième plus grosse demande dans les feedback (après l'antialiasing) ! Et moi, tu pense comme je suis pour à 200%. Boris ? Ca te dirais pas de fouiller du coté des matrice de déformation ??!
Aller... revenons à la version 1 qui n'existe pas encore. Je me répète : Quels objectifs, quels fonctionnalités en plus ou en moins (ex: antialiasing), quels bugs corrigés ou laissé en l'état ?
Non, je suis en escale chez moi pour quelques heures... Je repars ce soir.
dans 1156440182:
Bon, déjà , pour la mauvaise nouvelle (que l'écran blanc vienne d'un bug de QC) : Ca veut dire que t'as réussi à le faire reproduire chez quelqu'un de concerné, avec un autre module QC tout simple placé à la place de notre module ? Si c'est le cas : bon, il ne reste plus qu'à le préciser dans les bugs connus lors de la sortie de la prochaine version.
A part ça, comment envisage-tu l'avenir pour la version 1 Bru ?
Ce n'est pas reproductible sur toutes les configs. Pour le moment, impossible de savoir la cause. Ca ne semble qu'affecter le mode 2 (sur tous les écrans réunis). Est-ce dû à la taille de la fenêtre de rendu ? Est-ce dû à la version OpenGL du driver de la carte vidéo ? Ou alors peut-être que la fenêtre du rendu ne supporte pas d'être sur plusieurs écrans, chacun avec des résolutions/profondeurs différentes...
Pour la prochaine version, je pense livrer celle que j'ai actuellement (qui ne supporte pas encore les fenêtres filles). Elle est stable, et corrige quelques bugs de mémoire. Je pense qu'on peut la balancer en version 1.0.
dans 1156440182:
D'autre part, j'ai fait joujou avec la commande killall Dock : Effectivement, avec tout un tas de logiciels, ça marche impec' : c'est très impressionnant !!! Je suppose que tu envisage donc de travailler là dessus pour la version 2 ? Mais : - Qu'entends-tu par "matrice de déformation" ? C'est des sortes de mouvement type ? - Penses-tu que CoreAnimation puisse être utilisé comme matrice de déformation ? (bien que je trouve que cela rendrai la version 2 éllitiste à ceux qui ont léopard exclusivement...) - As-tu des pistes ou des contacts de gens qui connaissent et savent utiliser ces matrice de déformation ?
C'est clair que c'est très très prometteur. Que les contenus changent en temps réel est la deuxième plus grosse demande dans les feedback (après l'antialiasing) ! Et moi, tu pense comme je suis pour à 200%. Boris ? Ca te dirais pas de fouiller du coté des matrice de déformation ??!
Je joins à ce post une petite appli de démo. Je l'ai faite vite fait (et donc mal fait), alors indulgence. Au lancement de cette appli, choisir un fichier quicktime. Le fichier doit se jouer dans la fenêtre principale. Il y a aussi une petite palette en haut avec 2 boutons : Test et Réinit. Le bouton Test permet de choisir 4 points sur l'écran. Après appui, l'écran s'assombrit, et il suffit de cliquer 4 fois (un point rouge apparait à chaque clic). Chaque point correspond aux 4 coins de la future fenêtre à déformer. Le 1er point est le coin haut-gauche, le 2nd le haut-droite, le 3ème le bas-gauche et le dernier le bas-droite. Au 4ème clic, la fenêtre jouant le quicktime doit se déformer pour s'addapter à la nouvelle forme déterminée par les 4 clics. Le bouton Réinit réinitialise l'appli (plus de déformation, plus d'écran assombri).
Je joins à ce post une petite appli de démo. Je l'ai faite vite fait (et donc mal fait), alors indulgence. Au lancement de cette appli, choisir un fichier quicktime. Le fichier doit se jouer dans la fenêtre principale. Il y a aussi une petite palette en haut avec 2 boutons : Test et Réinit. Le bouton Test permet de choisir 4 points sur l'écran. Après appui, l'écran s'assombrit, et il suffit de cliquer 4 fois (un point rouge apparait à chaque clic). Chaque point correspond aux 4 coins de la future fenêtre à déformer. Le 1er point est le coin haut-gauche, le 2nd le haut-droite, le 3ème le bas-gauche et le dernier le bas-droite. Au 4ème clic, la fenêtre jouant le quicktime doit se déformer pour s'addapter à la nouvelle forme déterminée par les 4 clics. Le bouton Réinit réinitialise l'appli (plus de déformation, plus d'écran assombri).
Bon joujou.
.
C'est cool, ça fonctionne bien Y a plus qu'à faire bouger en 3D un rectangle fictif de la taille de la fenêtre et à faire la projection des quatre coins dans le plan puis appliquer à la vraie fenêtre
C'est cool, ça fonctionne bien  Y a plus qu'à faire bouger en 3D un rectangle fictif de la taille de la fenêtre et à faire la projection des quatre coins dans le plan puis appliquer à la vraie fenêtreÂ
Le principe est là !
La matrice de déformation que j'utilise ne se contente que de 4 points : les 4 coins de chaque fenêtre. Reste maintenant à créer une liste des quadruplets (4 points) à appliquer à la fenêtre à intervale régulier afin de simuler son déplacement/rotation. De plus, il faut plusieurs listes, pour que chaque fenêtre aie son déplacement/rotation propre. Et là , ça sort de mon domaine.
je ne garantis rien quant à mon temps disponible, mais ça m'intéresserait de regarder. Déjà voir la tête de la fonction undocumented et du code pour déformer les fenêtres, voir comment l'utiliser, et en suite faire mumuse avec pour rajouter une "grille" de points, calculer leurs coordonnées et tout.
j'ai déjà fait mumuse avec OpenGL et quelques notions de 3D donc si ça peut aider...
Par contre faudra que vous me disiez quels effets vous souhaitez avoir. Un effet 3D bête et méchant de projection d'un Quad sur l'écran, c'est jouable, même en se contentant des 4 points utilisés par Bru dans son appli de démo. Faire des formes plus originales du genre de celles de l'effet Génie c'est jouable aussi, mais faut juste trouver les belles fonctions mathématiques qui définissent la surface et déformation qu'on veut pour que ça donne un effet assez joli.
De toute façon y'a qu'en faisant mumuse avec qu'on pourra voir ce qui est possible.
C'est cool, ça fonctionne bien  Y a plus qu'à faire bouger en 3D un rectangle fictif de la taille de la fenêtre et à faire la projection des quatre coins dans le plan puis appliquer à la vraie fenêtreÂ
Le principe est là !
La matrice de déformation que j'utilise ne se contente que de 4 points : les 4 coins de chaque fenêtre. Reste maintenant à créer une liste des quadruplets (4 points) à appliquer à la fenêtre à intervale régulier afin de simuler son déplacement/rotation. De plus, il faut plusieurs listes, pour que chaque fenêtre aie son déplacement/rotation propre. Et là , ça sort de mon domaine.
Boris, t'es calé en 3D ?
.
Tu peux déjà voir si c'est jouable niveau proc et carte graphique assez facilement... Fais une dizaine de fenêtres contenant des films qui se jouent, pour chacune, tu prends un point aléatoire dans chaque quart de l'écran -> déformation Puis nouveaux points aléatoire pour chaque fenêtre, et déplacement des anciens vers les nouveaux de manière linéaire avec un NSTimer ; ça fera "danser" les fenêtres Â
J'aimerais bien voir la gueule de la fonction non documentée aussi J'ai essayé de mettre une dizaine de fenêtres dans le dock et de les sortir avec un effet lent (shift) toutes à la suite ; ça avait l'air jouable...
Ah ben oui ça c'est sur c'est du boulot. Et c'est pas notre petit Freeware qui va nous rémunérer ! ;D
Je me suis maté la keynote et la demo de leopard, et effectivement, il y a de grandes chances que CoreAnimation simplifie très très largement le boulot... quand il sera là .
Donc en attendant, si quelqu'un a envie de se plongé dnas les déformations 3D du type proposées par Bru, je vous donne juste mon point de vue : dans un premier temps, l'idée serait simplement de retrouver le même effet qu'actuellement : les fenêtres volent, plates, dans un espace ; le tout : en douceur (courbes de bezier de partout). C'est mon point de vue. Je pense que pour arriver à un truc pareil, y va y avoir, d'un un gros gros boulot perso, mais surtout une big organisation et méthodologie si vous bossez à deux ou plus ! Parce que jusque là , c'était simple : deux modules. Peut-être que dans la nouvelle méthode de Bru, ce sera plus complexe à mettre en oeuvre, non ? J'aime bien l'idée de shlum : fiare une appli test qui déforme aléatoirement 10 fenêtres dans dix lieux aléatoires. Ca permettrai de se rendre compte si ça passe !
Enfin, sur le petit joujou que Bru nous a donné : BRAVO ! Ca donne trop envie de voir notre bébé avec le contenu vivant !!! T'es fou de nous allêcher avec un joujou pareil Bru !
Enfin de enfin, Bru, pour la version 1, pourquoi n'envisage-tu pas d'inclure le système fenêtres filles/mères ? Se serai un petit plus qui amènerai tout le monde à le retélécharger non ?
Pour les animations supplémentaires, l'utilisation d'OpenGL, et les déformations autres, moi je suis prêt à donner un bon coup de main, surtout que j'ai déjà fait ça aussi un peu dans le cadre de mon boulot (je fais de la 3D au taf, mais à mon avis je suis moins calé que Boris).
Il est jouable sans trop de difficulité de réaliser en OpenGL par exemple un "effet vague" ou des choses comme ça. Mais du coup je suppose (mais je ne peux pas le dire tant que je n'ai pas vu la tête de la fonction undocumented que nous a déterré Bru ni fait quelques tests avec) que les WindowWarpers c'est pas dit qu'on arrive à faire ça (ça dépend de la tête de la matrice de déformation, etc). Enfin en OpenGL c'est pas dur y'a même le code sur NeHe, mais pour le WW je me prononcerai que quand j'aurais vu à quoi ressemble le proto et la matrice de transformation. Si on peut tesseler la fenêtre alors c'est gagné (et vu ce que dit Bru à priori c'est jouable puisque techniquement il nous dit qu'on peut déformer avec plus de 4 points), si c'est pas fait comme ça c'est une autre paire de manches.
...Déjà voir la tête de la fonction undocumented et du code pour déformer les fenêtres, voir comment l'utiliser, et en suite faire mumuse avec pour rajouter une "grille" de points, calculer leurs coordonnées et tout.
dans 1156528700:
J'aimerais bien voir la gueule de la fonction non documentée aussiÂ
dans 1156858212:
Mais du coup je suppose (mais je ne peux pas le dire tant que je n'ai pas vu la tête de la fonction undocumented que nous a déterré Bru ni fait quelques tests avec) que les WindowWarpers c'est pas dit qu'on arrive à faire ça (ça dépend de la tête de la matrice de déformation, etc). Enfin en OpenGL c'est pas dur y'a même le code sur NeHe, mais pour le WW je me prononcerai que quand j'aurais vu à quoi ressemble le proto et la matrice de transformation. Si on peut tesseler la fenêtre alors c'est gagné (et vu ce que dit Bru à priori c'est jouable puisque techniquement il nous dit qu'on peut déformer avec plus de 4 points), si c'est pas fait comme ça c'est une autre paire de manches.
La fonction undocumented se nomme CGSSetWindowWarp. Mais le mieux pour vous est de vous fournir le source du projet du "joujou" que j'ai fait pour le test.
Oui je suis calé en 3D, même que c'est mon boulot  8) Sur la 3D du coté programmation je connaissait, mais compte pas sur moi pour effectuer des opérations matricielles, j'ai abandonné tout ça :-* Trouver de la doc la dessus est assez facile, mais c'est du boulot...
Cool te revoilà Je te laisse voir aussi sur mes questionnements sur la v1... entre autres...
La grande question qui me vient : est-ce que l'on va pouvoir agir sur les fenêtres directement, sans avoir à patcher le dock... ou sans avoir à rien patcher du système... ?
Bon, à” joie, je viens de recevoir un vidéoprojecteur HDReady... donc je peux lui demander du 1920x1080 en second écran... donc devinez quoi : j'arrive à reproduire le bug de l'écran tout blanc/gris.
Alors bien sur de mon coté, j'ai fait quelques tests : - Cela ne vient pas du nombre de fenêtre... ni de leurs tailles... - Plus intéressant : j'ai modifier le .qtz pour ne laisser que le stricte minimum : le bug est toujours là : cela signifie que l'on ne pourrait pas contourner ce bug en modifiant la structure du .qtz. Tanpis.
La seule chose qui nous resterai à faire, éventuellement, serait de réussir à déterminer à partir de quelle surface en pixel carré, le bug commence à se produire... d'autant que je suppose que ça dépend de la carte graphique, et surement plus précisément de la quantité de VRAM... Il nous resterai à désactiver ce mode multi écran dans ce cas là . Bref... Très compliqué (trop même...non ?)
Pour l'instant, je pense qu'on peut s'en tenir à annoncer que ce bug existe (faute à Apple), et je propose que le mode multi ecran par défault passe à "chaque écran son anim' ". Z'en dites quoi ?
Alors... pour cette version 1 ? Bru ? T'en dis quoi d'mes questions de quelques postes plus haut ?
Réponses
Pense donc que j'ai un mail, si je peux aider à tester... même si j'ai pas le bug de l'écran blanc.
Ce n'est pas un bug...
IB utilise une fenêtre-fille transparente de même "niveau" qu'une fenêtre document pour afficher le cadre de sélection (mais aussi divers autres éléments).
D'un point de vue système, c'est donc une fenêtre comme les autres.
Par contre, ça illustre le soucis des fenêtre filles (comme les sheets ou drawers) : en effet, actuellement, je n'arrive pas à récupérer l'info comme quoi la fenêtre est une fille, ni qu'elle est sa mère.
Si je le savais, cela permettrait de recomposer une seule image de fenêtre en ré-assemblant la mère et ses filles.
.
Ca n'a jamais été un bug...
Dans ce post, j'expliquai :
Mais, quelques posts plus loin, on pouvait lire dans ce message :
Donc, j'ai supprimé cette désactivation, comme relaté dans ce post :
.
Je sais que tu avais désactivé la suspension d'activité de l'écran. Et je t'avais relaté que chez moi mon iMac ne se mettais pas en veille (suspension activité du mac).
Evidemment il y avait 99% de chances que ce soit lié, c'était limite une évidence. Mais fallait bien que je confirme que depuis que tu as enlevé ce truc pour empêcher la suspension de l'écran, le bug inhérent (le fait que ça empêchait *aussi* la suspension du mac) a du coup disparu.
Ca semblait évident, mais bon, j'ai déjà rencontré des bugs où j'étais sûr de savoir doù ça venait et en fait m'étais totalement gourré, alors fallait bien que je confirme, on ne peut fermer un bug qu'après avoir passé la phase de test validant qu'il n'apparaà®t plus du moins dans les conditions où avant il apparaissait.
C'est peut être de nouvelles perpectives pour l'économiseur.
Ca m'a pris 3 heures hier, mais j'ai pu une fois de plus hacker le window-server : maintenant, je peux savoir si une fenêtre est fille (donc attachée à une fenêtre mère), et je peux savoir qui est la mère.
Donc, grande conséquence : les drawers, sheets et autres trucs bizarres à la IB (cf le post d'Eddy) seront envoyés au module .qtz dans la même image que leur mère.
De plus, si à la WWDC, et suite à l'implantation des multiples bureaux dans le 10.5, je vais essayer d'anticiper çà en n'envoyant au module .qtz que les fenêtres appartenant au bureau affiché.
.
T'es un bon !!!
Alors finalement ? Quand espère-tu pouvoir la rendre publique ?
Quelles nouvelles ? T'es déjà parti en vacances Bru ?
Bon, bien sur, l'actualité de la WWDC a fait que ça s'est calmé pour nous... je n'ai plus eu de rapport de bug depuis une semaine. Logique...
Et toi hokstitan, t'as pu voir les stats ?
Et toi Boris, t'es revenu ? T'as vu comme ça a bien marché ?? :adios!:
En allant à droite à gauche j'ai pu voir que dans l'ensemble les gens étaient plutot satisfait. Voir impressionné. ::)
Reste le problème des perfs. Certains se plaignent de surchauffe, des ventilos qui turbinent des ressources bouffés et j'en passe. Quartz composer tire partie du GPU, alors bien sur avec un carte video vieille ou pas performante il est difficile de profiter de l'accélération graphique des cartes. A titre info un mac mini G4 a 32M de mémoire vidéo, sur le macmini intel ya même plus de mémoire video, elle est partagée avec la ram (il me semble) alors les perfs sont pas terribles c'est vrai, mais je suis pas sur qu'en programmant le tout diretc en OGL on gagne beaucoup.
Il faudrait faire un calcul rapide pour voir combien de Vram est bouffé par les textures qui sont envoyées à la carte. Chez moi j'ai une résolution de 1080x1024, alors rien que ça, ça fait une texture de 5M, plus la mémoire pour l'affichage on arrive à 10M, on doit arriver facilement à dépasser 32M. Je pense que sur des petites configs il faudrait envoyer des texures en quart de définition.
Bon... oui, effectivement, il y a quelques plainte de vitesse et de charge processeur. Cela dit, ça va s'estomper très rapidement ces remarques... Plus ça va, plus les machines seront capables de le faire fonctionner sans surcharge (grace à un repport de 100% sur le GPU).
Quant à la solution de baisser la résolution, j'en suis pas fan dutout : l'effet des fenêtres qui se décollent risquerai d'être cassé puisque d'un coup tout deviendrai flou/moche.
Donc tu confirme qu'un développement en OpenGL directement ne ferai pas tant gagner que ça. Bon. C'est bien ce que je me disais.
Perso, j'ai reçu beaucoup de demande de gens qui ont des grosses config, et qui auraient souhaité pouvoir activer les deux anti aliasing possible (celui interne au fenêtre, et celui des bords des fenêtres).
Evidement, l'autre demande serait que le contenu soit mis à jour. Et là , c'est une question à Bru pour quand il reviendra : est-ce que l'on ne pourrait pas mettre à jour le contenu toutes les 20 secondes ? (enfin je sais même pas si ce serait une bonne idée...)
Enfin, une troisième grosse demande, c'est que le bureau reste plein de son contenu et de la barre des menus... est-ce que Bru, t'arriverai à "recréer" l'image du bureau complet à partir de tous ses éléments ? (sachant que maintenant, tu sais trouver les éléments "fils" et "Parents")
Mais quoi qu'il en soit, pour l'instant, focalisons-nous sur une version débuggée. Avant tout. Après, si dans cette version débuggée, on y ajoute une fonction "Bonus"... ça permettrai de relancer buzz autour de notre "bébé"
Ciao ! Et bon retour parmis nous Boris !
J'ai fait un peu joujou avec OpenGL il y a 2 ans, et en effet, comme il y a peu d'objets (de triangles), le gros du travail est de plaquer les textures, tâche qui revient au processeur graphique. Bref, il est peu probable de gagner en vitesse.
Il est préférable que toutes les textures soient mises dans la RAM vidéo pour des questions de performances. Mais pas obligatoire, il me semble en OpenGL.
Une astuce: le fond d'écran est à environ 1/4 de sa taille d'origine une fois au fond. Peut-être pourriez vous diviser par 2 ses dimensions avant de la mettre en VRAM. Je pense que la dégradation serait peu visible.
Haute qualité - Gourmand en ressources :
- Active les anti-aliasing possibles
Normal (par défaut):
- Comme actuellement
Basse qualité - Economique en ressources :
- Réduise l'ensemble des textures par 2 (mais gagnera-t-on réellement en fps ? ou en % d'occupation processeur ?)
- Réduise le fps à 30fps (est-ce techniquement possible avec QC ?)
Qu'en dites-vous Bru et Boris ?
J'envisage ça pour la prochaine beta en fait. Ce qui donnera comme nouvelles fonctionnalités :
- antialising (une très grosse demande dans les feed-back)
- Fenêtres filles attachées aux mères (que Bru à déka implémenté je crois)
Ca me paraà®t être un bon objectif pour cette version 1.
Le bug de l'écran blanc est un bug de Quartz Composer. Et je n'ai aucun moyen de le contourner.
Donc, je ne pourrais rien faire de ce côté.
Par contre, je pense au futur (notamment, la mise à jour du contenu des fenêtres). Et là , le plus simple est d'abandonner Quartz Composer, et de jouer directement avec le window-warping.
Le window-warping est la possibilité d'appliquer aux fenêtres une matrice de déformation. J'ai enfin terminé de désassembler la fonction qui permet celà , et je commence à maà®triser les déformations.
J'en reparlerai à mon retour de vacances (à la "rentrée").
.
La fonction de recopie d'écran (et de fenêtre) est gourmande en temps.
Les essais que j'ai réalisé pour mettre à jour le contenu des fenêtres (j'avais réglé le délai de mise à jour à 10 secondes) ont montré des performances catastrophiques.
Pendant chaque mise à jour d'une seul fenêtre, l'animation QC se fige, puis reprend avec une espèce de "bond". Je ne sais pas si tu peux maà®triser ça dans le module.
Concernant le window-warping : il faut créer des matrices de déformations pour pouvoir les appliquer par la suite aux fenêtres. Cela dépasse mes compétences. Quiconque est intéressé par ça est le bienvenu ! Donc, non, je ne programmerai pas tout par moi-même.
Pour expliquer les possibilités du window-warping, tu peux faire un test : ouvre une fenêtre du terminal, et tape la commande suivante sans l'exécuter :
[tt]killall Dock[/tt]
Ensuite choisis une fenêtre (si possible la plus grande, et pourquoi, une fenêtre animée -genre un quicktime, ou une pag web- ). Miniaturise cette fenêtre tout en pressant la touche SHIFT : la fenêtre est aspirée par le Dock très lentement.
Très vite (sans lacher SHIFT) retourne dans le terminal et valide ta commande (en tapant RETURN).
Tu verras alors ta fenêtre se figer dans sa déformation. Et surtout, tu peux voir cette fenêtre pleinement fonctionnelle (tu peux la déplacer si tu arrives à choper la barre de titre), et surtout, son contenu est vivant.
.
Bon, déjà , pour la mauvaise nouvelle (que l'écran blanc vienne d'un bug de QC) : Ca veut dire que t'as réussi à le faire reproduire chez quelqu'un de concerné, avec un autre module QC tout simple placé à la place de notre module ? Si c'est le cas : bon, il ne reste plus qu'à le préciser dans les bugs connus lors de la sortie de la prochaine version.
A part ça, comment envisage-tu l'avenir pour la version 1 Bru ?
D'autre part, j'ai fait joujou avec la commande killall Dock : Effectivement, avec tout un tas de logiciels, ça marche impec' : c'est très impressionnant !!! Je suppose que tu envisage donc de travailler là dessus pour la version 2 ? Mais :
- Qu'entends-tu par "matrice de déformation" ? C'est des sortes de mouvement type ?
- Penses-tu que CoreAnimation puisse être utilisé comme matrice de déformation ? (bien que je trouve que cela rendrai la version 2 éllitiste à ceux qui ont léopard exclusivement...)
- As-tu des pistes ou des contacts de gens qui connaissent et savent utiliser ces matrice de déformation ?
C'est clair que c'est très très prometteur. Que les contenus changent en temps réel est la deuxième plus grosse demande dans les feedback (après l'antialiasing) ! Et moi, tu pense comme je suis pour à 200%. Boris ? Ca te dirais pas de fouiller du coté des matrice de déformation ??!
Aller... revenons à la version 1 qui n'existe pas encore. Je me répète : Quels objectifs, quels fonctionnalités en plus ou en moins (ex: antialiasing), quels bugs corrigés ou laissé en l'état ?
Non, je suis en escale chez moi pour quelques heures... Je repars ce soir.
Ce n'est pas reproductible sur toutes les configs.
Pour le moment, impossible de savoir la cause.
Ca ne semble qu'affecter le mode 2 (sur tous les écrans réunis). Est-ce dû à la taille de la fenêtre de rendu ? Est-ce dû à la version OpenGL du driver de la carte vidéo ? Ou alors peut-être que la fenêtre du rendu ne supporte pas d'être sur plusieurs écrans, chacun avec des résolutions/profondeurs différentes...
Pour la prochaine version, je pense livrer celle que j'ai actuellement (qui ne supporte pas encore les fenêtres filles).
Elle est stable, et corrige quelques bugs de mémoire.
Je pense qu'on peut la balancer en version 1.0.
Je joins à ce post une petite appli de démo. Je l'ai faite vite fait (et donc mal fait), alors indulgence.
Au lancement de cette appli, choisir un fichier quicktime.
Le fichier doit se jouer dans la fenêtre principale.
Il y a aussi une petite palette en haut avec 2 boutons : Test et Réinit.
Le bouton Test permet de choisir 4 points sur l'écran. Après appui, l'écran s'assombrit, et il suffit de cliquer 4 fois (un point rouge apparait à chaque clic). Chaque point correspond aux 4 coins de la future fenêtre à déformer. Le 1er point est le coin haut-gauche, le 2nd le haut-droite, le 3ème le bas-gauche et le dernier le bas-droite. Au 4ème clic, la fenêtre jouant le quicktime doit se déformer pour s'addapter à la nouvelle forme déterminée par les 4 clics.
Le bouton Réinit réinitialise l'appli (plus de déformation, plus d'écran assombri).
Bon joujou.
.
[Fichier joint supprimé par l'administrateur]
C'est cool, ça fonctionne bien
Y a plus qu'à faire bouger en 3D un rectangle fictif de la taille de la fenêtre et à faire la projection des quatre coins dans le plan puis appliquer à la vraie fenêtre
Le principe est là !
La matrice de déformation que j'utilise ne se contente que de 4 points : les 4 coins de chaque fenêtre.
Reste maintenant à créer une liste des quadruplets (4 points) à appliquer à la fenêtre à intervale régulier afin de simuler son déplacement/rotation.
De plus, il faut plusieurs listes, pour que chaque fenêtre aie son déplacement/rotation propre.
Et là , ça sort de mon domaine.
Boris, t'es calé en 3D ?
.
je ne garantis rien quant à mon temps disponible, mais ça m'intéresserait de regarder. Déjà voir la tête de la fonction undocumented et du code pour déformer les fenêtres, voir comment l'utiliser, et en suite faire mumuse avec pour rajouter une "grille" de points, calculer leurs coordonnées et tout.
j'ai déjà fait mumuse avec OpenGL et quelques notions de 3D donc si ça peut aider...
Par contre faudra que vous me disiez quels effets vous souhaitez avoir. Un effet 3D bête et méchant de projection d'un Quad sur l'écran, c'est jouable, même en se contentant des 4 points utilisés par Bru dans son appli de démo. Faire des formes plus originales du genre de celles de l'effet Génie c'est jouable aussi, mais faut juste trouver les belles fonctions mathématiques qui définissent la surface et déformation qu'on veut pour que ça donne un effet assez joli.
De toute façon y'a qu'en faisant mumuse avec qu'on pourra voir ce qui est possible.
Tu peux déjà voir si c'est jouable niveau proc et carte graphique assez facilement...
Fais une dizaine de fenêtres contenant des films qui se jouent, pour chacune, tu prends un point aléatoire dans chaque quart de l'écran -> déformation
Puis nouveaux points aléatoire pour chaque fenêtre, et déplacement des anciens vers les nouveaux de manière linéaire avec un NSTimer ; ça fera "danser" les fenêtres Â
J'aimerais bien voir la gueule de la fonction non documentée aussiÂ
J'ai essayé de mettre une dizaine de fenêtres dans le dock et de les sortir avec un effet lent (shift) toutes à la suite ; ça avait l'air jouable...
Sur la 3D du coté programmation je connaissait, mais compte pas sur moi pour effectuer des opérations matricielles, j'ai abandonné tout ça :-*
Trouver de la doc la dessus est assez facile, mais c'est du boulot...
Je me suis maté la keynote et la demo de leopard, et effectivement, il y a de grandes chances que CoreAnimation simplifie très très largement le boulot... quand il sera là .
Donc en attendant, si quelqu'un a envie de se plongé dnas les déformations 3D du type proposées par Bru, je vous donne juste mon point de vue : dans un premier temps, l'idée serait simplement de retrouver le même effet qu'actuellement : les fenêtres volent, plates, dans un espace ; le tout : en douceur (courbes de bezier de partout). C'est mon point de vue.
Je pense que pour arriver à un truc pareil, y va y avoir, d'un un gros gros boulot perso, mais surtout une big organisation et méthodologie si vous bossez à deux ou plus ! Parce que jusque là , c'était simple : deux modules. Peut-être que dans la nouvelle méthode de Bru, ce sera plus complexe à mettre en oeuvre, non ?
J'aime bien l'idée de shlum : fiare une appli test qui déforme aléatoirement 10 fenêtres dans dix lieux aléatoires. Ca permettrai de se rendre compte si ça passe !
Enfin, sur le petit joujou que Bru nous a donné : BRAVO ! Ca donne trop envie de voir notre bébé avec le contenu vivant !!! T'es fou de nous allêcher avec un joujou pareil Bru !
Enfin de enfin, Bru, pour la version 1, pourquoi n'envisage-tu pas d'inclure le système fenêtres filles/mères ? Se serai un petit plus qui amènerai tout le monde à le retélécharger non ?
Il est jouable sans trop de difficulité de réaliser en OpenGL par exemple un "effet vague" ou des choses comme ça.
Mais du coup je suppose (mais je ne peux pas le dire tant que je n'ai pas vu la tête de la fonction undocumented que nous a déterré Bru ni fait quelques tests avec) que les WindowWarpers c'est pas dit qu'on arrive à faire ça (ça dépend de la tête de la matrice de déformation, etc).
Enfin en OpenGL c'est pas dur y'a même le code sur NeHe, mais pour le WW je me prononcerai que quand j'aurais vu à quoi ressemble le proto et la matrice de transformation. Si on peut tesseler la fenêtre alors c'est gagné (et vu ce que dit Bru à priori c'est jouable puisque techniquement il nous dit qu'on peut déformer avec plus de 4 points), si c'est pas fait comme ça c'est une autre paire de manches.
Je répondrais à tous vos messages très bientôt !
.
La fonction undocumented se nomme CGSSetWindowWarp. Mais le mieux pour vous est de vous fournir le source du projet du "joujou" que j'ai fait pour le test.
.
[Fichier joint supprimé par l'administrateur]
Dommage...
.
La grande question qui me vient : est-ce que l'on va pouvoir agir sur les fenêtres directement, sans avoir à patcher le dock... ou sans avoir à rien patcher du système... ?
Bon, à” joie, je viens de recevoir un vidéoprojecteur HDReady... donc je peux lui demander du 1920x1080 en second écran... donc devinez quoi : j'arrive à reproduire le bug de l'écran tout blanc/gris.
Alors bien sur de mon coté, j'ai fait quelques tests :
- Cela ne vient pas du nombre de fenêtre... ni de leurs tailles...
- Plus intéressant : j'ai modifier le .qtz pour ne laisser que le stricte minimum : le bug est toujours là : cela signifie que l'on ne pourrait pas contourner ce bug en modifiant la structure du .qtz. Tanpis.
La seule chose qui nous resterai à faire, éventuellement, serait de réussir à déterminer à partir de quelle surface en pixel carré, le bug commence à se produire... d'autant que je suppose que ça dépend de la carte graphique, et surement plus précisément de la quantité de VRAM... Il nous resterai à désactiver ce mode multi écran dans ce cas là . Bref... Très compliqué (trop même...non ?)
Pour l'instant, je pense qu'on peut s'en tenir à annoncer que ce bug existe (faute à Apple), et je propose que le mode multi ecran par défault passe à "chaque écran son anim' ". Z'en dites quoi ?
Alors... pour cette version 1 ? Bru ? T'en dis quoi d'mes questions de quelques postes plus haut ?