Réaliser un projet de crowdsourcing sur Canvas - page 18
Vous manquez des opportunités de trading :
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Inscription
Se connecter
Vous acceptez la politique du site Web et les conditions d'utilisation
Si vous n'avez pas de compte, veuillez vous inscrire
Malheureusement, les tentatives actuelles pour résoudre le problème de la mise à jour tardive des images en sauvegardant un tableau avec un "masque numérique" n'ont pas été couronnées de succès. Cependant, ce n'est pas non plus un échec. Il n'a tout simplement pas été possible de tirer une conclusion définitive sur la cause du retard et de trouver une solution globale au problème.
En réfléchissant à des méthodes générales pour stocker l'image finie en mémoire et travailler avec ses zones, j'ai passé en revue différentes options. Celles que je pensais être une bonne solution, mais qui, après mûre réflexion, se sont avérées peu pratiques.
Et donc - mes conclusions :
1. Si vous voulez sauvegarder des images dans des tableaux, il doit y avoir beaucoup de tableaux. En d'autres termes, chaque ressource nécessite son propre tableau de mémoire constante. Dans mon implémentation, le nombre de toiles (ressources, toiles) pourrait être plusieurs fois supérieur au nombre de fenêtres.
Je vais vous expliquer pourquoi :
Dans certains cas, cette approche est beaucoup plus pratique que de dessiner tous les objets de la fenêtre sur un seul canevas, par exemple, lorsque l'on fait défiler un tableau dans un élément "champ de vision (VEIW BOX)", il est pratique de placer les éléments du tableau sur un canevas séparé à l'intérieur de cet élément et de faire défiler ce canevas comme un objet entier. La vitesse de défilement est plus rapide. Ainsi, chaque élément de ce type porte en lui un kanvas distinct. Sinon, il devra écraser l'image entière de la fenêtre sauvegardée en mémoire. Cela vous prendra certainement beaucoup plus de temps.
De plus, il est assez peu pratique de dessiner toutes les fenêtres sur une seule toile, comment les déplacer alors ? Supposons que nous créions un "méga" canevas pour l'ensemble de la zone du graphique. Toutes nos fenêtres seront dessinées dessus. Après avoir dessiné les fenêtres sur le kanvas, nous essaierons de les déplacer, mais pour ce faire, nous devrons réécrire toute l'image de ce "méga" kanvas unique. Le tableau est très vaste et la quantité de valeurs réécrites sera énorme. Même si l'image est sauvegardée, nous devrons écraser une énorme zone de la mémoire à chaque déplacement du curseur. C'est évidemment inefficace.
2. En pensant à une méthode pour sauvegarder les images et travailler avec elles, je me suis souvenu de la fonction "ResourceReadImage()". Cette fonction lit la ressource et place son masque numérique dans un tableau. Ainsi, - il n'est pas nécessaire de sauvegarder l'image, car elle est déjà sauvegardée au niveau du terminal et peut être appelée à l'aide de cette fonction. Cela simplifie grandement la tâche. Ainsi, vous pouvez récupérer l'image à l'aide de la fonction "ResourceReadImage()", la placer dans un tableau et modifier les valeurs de ce tableau en fonction d'un élément particulier qui se trouve "sous l'événement" de l'interface. Cette approche me semble plus attrayante. Cependant, la question demeure : combien de temps faudra-t-il pour remplir le tableau avec une image en utilisant "ResourceReadImage()" ? Évidemment, cela dépend aussi de la zone du kanvas. Il se peut qu'il ne soit pas du tout visible visuellement, mais dans tous les cas, il ne doit être chargé qu'une seule fois lorsque le curseur se trouve sur une zone particulière du kanvas. Lorsque vous passez à un autre kanvas, vous pouvez effacer le tableau et télécharger l'image de l'autre kanvas.
Quoi qu'il en soit, je n'ai pas de solution définitive pour le moment. Je dois essayer avec la fonction "ResourceReadImage()", mesurer le temps de chargement de l'image et développer un système pour travailler avec les zones de l'image dans le tableau.
C'est tout pour le moment.Реter Konow:
Dans mon implémentation de l'interface, le nombre de toiles (ressources, toiles) peut être plusieurs fois supérieur au nombre de fenêtres, ce qui est requis par la pratique.
Votre pratique l'exige.
Mais comme le montre votre propre pratique, cette mise en œuvre est défectueuse en termes de rapidité et de commodité.
Comme la pratique le montre, il est plus pratique de travailler avec un seul canevas et il n'y a aucun obstacle à dessiner temporairement une fenêtre de table sur votre canevas et à utiliser ensuite BitBlt sur la fenêtre principale.
Je ne sais pas pourquoi vous avez prévu "il doit y avoir beaucoup de tableaux". "Mais vous voyez vous-même que c'est une voie sans issue.
C'est ce que votre pratique exige.
Mais comme le montre votre propre pratique, une telle mise en œuvre est déficiente en termes de rapidité et de commodité.
Comme la pratique le montre, il est plus pratique de travailler avec un seul canevas et il n'y a aucun obstacle à dessiner temporairement une fenêtre de table sur votre canevas et à utiliser ensuite BitBlt sur la fenêtre principale.
Je ne sais pas pourquoi vous avez prévu "il doit y avoir beaucoup de tableaux, de plus - indéfiniment beaucoup...". "Mais vous voyez vous-même que c'est une voie sans issue.
Peut-être avez-vous trouvé une meilleure solution. J'aimerais bien le voir. Si vous le pouvez, postez un gif où l'on peut clairement voir la vitesse de réponse des éléments au clic. Je posterai mon gif après. Vous verrez ce dont je parle et je verrai ce dont vous parlez.
Je n'ai pas enregistré la vidéo, mais je vous envoie un exemple. C'est un croquis rapide.
Il existe 600 listes déroulantes.
Déplacez la souris - à chaque événement et changement de couleur, le CCanvas global est redessiné. Vous obtenez cette interactivité.
Vous pouvez voir la taille finale dans les propriétés du bitmap - 1500x600 px (comparé à vos 800x500 et 250ms de décalage). Ce qui équivaut à 900 000 pixels, et tous sont redessinés instantanément. Aucune seconde n'est à exclure.
Chaque liste est d'abord rendue sur son propre canevas dans sa propre taille (pour ne pas déborder) et ensuite approfondie sur l'ensemble. Nous avons donc 600 appels ResourceCreate par événement de souris.
Cela signifie, comme vous pouvez le constater par la vitesse de réaction, que les images sont suffisantes pour montrer des dessins animés.
Les développeurs de MT ont fourni un outil satisfaisant et sans décalage (je parle de ResourceCreate bitmaps).
Je n'ai pas enregistré la vidéo, mais je vous envoie un exemple.
il y a 600 listes déroulantes.
Déplacez la souris - à chaque événement et changement de couleur, le CCanvas global est redessiné.
Vous pouvez voir la taille finale dans les propriétés du bitmap - 1500x600 px (comparé à vos 800x500 et 250ms de décalage). Ce qui équivaut à 900 000 pixels, et tous sont redessinés instantanément. Aucune seconde n'est à exclure.
Chaque liste est d'abord rendue sur son propre canevas dans sa propre taille (pour ne pas déborder) et ensuite approfondie sur l'ensemble. Nous avons donc 600 appels ResourceCreate par événement de souris.
Cela signifie, comme vous pouvez le constater par la vitesse de réaction, que les images sont suffisantes pour montrer des dessins animés.
Les développeurs de MT ont fourni un outil satisfaisant et sans décalage (je parle de ResourceCreate bitmaps).
Eh bien, c'est suffisant pour confirmer vos dires... Cependant, je répète ma question d'hier : l'image est-elle sauvegardée ?
Je l'ai dit hier - si vous stockez une image créée une fois, modifiez seulement une zone spécifique, et envoyez immédiatement à ResourceCreate(), il n'y aura pas de retard. Votre méthode de travail avec la toile ne m'est pas encore familière. Je ne sais pas encore comment vous avez obtenu ce résultat.
J'ai une autre question : en utilisant la classe CCanvas pour créer l'exemple ci-dessus, pourriez-vous décrire le principe de mise en œuvre de cette solution ?
Peut-être que des opérations par bit y sont utilisées pour traiter l'image. Je n'ai pas encore eu affaire à eux.
P.S. Cependant, j'aime résoudre les secrets moi-même...) Je vais quand même résoudre ce problème.
en utilisant la classe CCanvas pour créer l'exemple ci-dessus, pouvez-vous décrire le principe de mise en œuvre de cette solution ?
le principe est linéaire : parcourez la liste des contrôles et dessinez chacun d'entre eux à la position requise sur le canevas.
Seules les fonctions CCanvas sont utilisées pour dessiner les contrôles. Je n'ai rien dessiné de mon cru.
Par exemple, les listes dans le formulaire réduit sont dessinées comme deux éléments - dans cet exemple, des boutons (c'est différent dans d'autres styles).
les fonctions de canevas sont appelées
FillRectangle // remplissage du fond
Rectangle // cadre autour
FontSet // définit la police
TextOut // texte de sortie
Il est possible que des opérations par bit y soient utilisées pour traiter l'image.
non.
l'image est-elle sauvegardée ?
oui, dans le tableau qui est dans CCanvas
si vous stockez une image une fois créée, que vous n'en modifiez qu'une zone spécifique et que vous l'envoyez immédiatement à ResourceCreate(), il n'y aura aucun délai.
pas tout à fait juste.
Dans mon exemple, le tableau entier est redessiné. Le tableau est effacé et le canevas entier est rempli à nouveau à chaque redessin. Ensuite, ResourceCreate est appelé.
Dans mon exemple, le tableau entier est redessiné. Le tableau est effacé et le canevas entier est rempli à nouveau à chaque redessin. Ensuite, ResourceCreate est appelé.
Merci pour cette réponse élaborée.
Bizarrement, c'est la même chose pour moi. L'image de la fenêtre entière est entièrement recréée à chaque événement d'interface. Il est construit dans un tableau local à une dimension, qui est envoyé à ResourceCreate après la fin de cette procédure.
Je ne sais pas pourquoi ça me ralentit... Demain, je posterai un gif où je montrerai la corrélation entre la taille de la fenêtre et la vitesse de réponse des éléments.
Tout ceci est très étrange...
Merci pour cette réponse détaillée.
Bizarrement, c'est la même chose pour moi. L'image de la fenêtre entière est entièrement recréée à chaque événement d'interface. Il est construit dans un tableau local à une dimension, qui est envoyé à ResourceCreate après la fin de cette procédure.
Je ne sais pas pourquoi ça me ralentit... Demain, je posterai un gif où je montrerai la dépendance entre la taille de la fenêtre et la vitesse de réponse des éléments.
Tout ceci est très étrange...
Si ce n'est pas difficile, faites une animation gif avec la charge CPU dans le gestionnaire de tâches. Ou bien il est plus facile de poster le fichier compilé, comme l'a faitsergeev. On peut donc le tester soi-même.
OK, je vais faire une vidéo de la charge du CPU. Mais en ce qui concerne le fichier compilé - je ne le posterai pas encore.
Juste très honteux des insectes...))
Quand je les aurai réparés, je promets de les poster.
OK, je vais faire une vidéo de la charge du CPU. Mais en ce qui concerne le fichier compilé - je ne le posterai pas encore.
Juste très honteux des insectes...))
Quand je les aurai réparés, je promets de les poster.