Hum, ça ne résout pas le problème des défilements rapides...
Je ne pense pas qu'il y ai un problème tant que le mécanisme reconstitue les tuiles en avance sur le défilement. Le delegué de UIScrollView reçoit les événements de scrolling au fur et à mesure, non ? Cela permet donc de pré-dessiner les tuiles nécessaires.
Justement, là réside problème: le dessin ne peut pas être en avance sur le défilement parce que dessiner prend trop de temps. Si le dessin allait plus vite que le défilement, alors on n'observerait pas de problème de fluidité actuellement.
À mon avis, on ne peut pas rendre cela beaucoup plus rapide à moins d'accélérer le rendu vectoriel pendant le défilement: - désactiver l'anti-aliasing (à essayer: simple et efficace) - désactiver les transparences - ne pas dessiner les lignes trop fines etc.
Justement, là réside problème: le dessin ne peut pas être en avance sur le défilement parce que dessiner prend trop de temps. Si le dessin allait plus vite que le défilement, alors on n'observerait pas de problème de fluidité actuellement.
À mon avis, on ne peut pas rendre cela beaucoup plus rapide à moins d'accélérer le rendu vectoriel pendant le défilement: - désactiver l'anti-aliasing (à essayer: simple et efficace) - désactiver les transparences - ne pas dessiner les lignes trop fines etc.
Oui tout à fait.
Je ne savais pas que l'on pouvait désactiver l'anti-aliasing, effectivement à essayer. Par contre je n'utilise pas (encore) les transparences. Ne pas dessiner les lignes trop fines, à essayer aussi. Déjà je remplace les textes trop petits par des rectangles gris.
Les visualisateurs de fichiers DXF utilisent OpenGL, c'est rapide mais moins joli notamment pour le texte. Avec GLKit de iOS 5, il faudra que je regarde mais OpenGL me semble très compliqué.
Tout cela n'apportera qu'un gain négligeable. Pour améliorer les performances d'une application graphique, il faut utiliser le vectoriel au minimum en le rasterisant (faire un aplat bitmap) dès que faire se peut. Par exemple, à un zoom donné on calcul le rendu bitmap de tous les objets. Ensuite lors d'un scroll on ne fait que réafficher le bitmap de chaque objet.
Tout cela n'apportera qu'un gain négligeable. Pour améliorer les performances d'une application graphique, il faut utiliser le vectoriel au minimum en le rasterisant (faire un aplat bitmap) dès que faire se peut. Par exemple, à un zoom donné on calcul le rendu bitmap de tous les objets. Ensuite lors d'un scroll on ne fait que réafficher le bitmap de chaque objet.
Sans avoir réfléchi, 2 remarques : l'encombrement mémoire ? superposition des objets ?
Pour l'encombrement mémoire, plus on dézoome et plus les objets bitmap obtenus sont petits. On peut aussi imaginer des optimisations assez simple genre: en cas d'alerte mémoire du device on libère une partie des caches avec comme priorité les plus gros objets.
Pour la superposition, il n'y a pas plus de problème qu'en vectoriel. Il suffit d'afficher les bitmaps en respectant la même hiérarchie.
Un exemple avec deux lignes à 45° qui se croisent. Si chacune fait 200 pixels x 200 pixels, il faut donc 2 bitmaps de 200x200 pixels juste pour 2 lignes !? En dessinant les 2 bitmaps l'une sur l'autre, le fond de la 2ème va écraser la première ou bien il faut un fond transparent. Cela est-il possible ?
On peut tout à fait faire des bitmaps transparentes (c'est le cas des .png), mais effectivement, ça prend une mémoire énorme, alors il faudrait utiliser des caches disque.
On peut tout à fait faire des bitmaps transparentes (c'est le cas des .png), mais effectivement, ça prend une mémoire énorme, alors il faudrait utiliser des caches disque.
C'est infiniment plus rapide de tracer ces lignes avec OpenGL !
Tracer des lignes en OpenGL oui. Maintenant, si on parle par exemple d'un texte ou d'autres objets un peu complexe il faudra de toute façon passer par une texture qui impose d'avoir généré un bitmap...
Moi sur ce genre de projet mon approche serait: qu'est ce qui existe déjà et comment l'améliorer substantiellement sans tout casser.
L'utilisation d'un cache bitmap est d'autant plus efficace que l'objet est complexe. J'aurais donc tendance à porter mon attention tout particulièrement sur le rafraichissement des textes par exemple dans un premier temps.
Le device a ici un espace mémoire limité. Donc je le prendrais aussi en compte pour mon architecture. En partant du prorata de bitmaps avec une couche alpha pour la transparence, le tout avec 8bits par couche, je suis à 4 octets par pixel. Il est facile de mettre en place un petit système de gestion de cache centralisé. Lorsqu'un objet a besoin de se dessiner, il demande au gestionnaire de cache: - j'ai besoin de 200x200x4 octets. Est-ce ok pour toi? - Ouai pas de problème j'ai largement ce qu'il te faut. Sinon il répond non et l'objet se dessine en vectoriel à moins que le gestionnaire de cache face de la place du fait que des objets sont hors champ. Si ok, l'objet informe le gestionnaire de cache (un singleton?) de la mémoire qu'il a utilisé afin que celui-ci en tienne compte et le référence.
Bref c'est pas très lourd à développer et le gain est garanti. C'est ce que je fais tous les jours sur Mac avec Core Animation entre autre.
PS: concernant OpenGL cela devient vite très complexe à gérer et cela sans doute encore plus sur un petit device.
J'ai commencé à prendre vos remarques en compte : - Draken, j'ai mis la StatusBar transparente et en plus je la cache en même temps que l'UI lors de touches; Cela m'a posé quelques problèmes de décalage de vues mais a priori c'est résolu et cela fonctionne bien.
- Pour la vitesse de scrolling, si certains ont fait des tests sur iPad, vous avez peut-être remarqué que les scrollings sont plus rapides. Cela parce que sur les écrans non Rétina, je bouge la bitmap du dessin et ne redessine que la portion scrollée. Je n'avais pas finalisée cette procédure sur l'écran Rétina à cause d'un floutage du dessin donc je redessinais tout à chaque fois. En cherchant un peu, j'ai trouvé qu'il faut utiliser "UIGraphicsBeginImageContextWithOptions" pour les écrans Rétina. Maintenant cela fonctionne aussi sur Rétina mais j'ai encore un petit décalage qui apparaà®t de temps en temps à la jonction avec la zone mise à jour.
Vous aurez donc ces nouveautés dans la prochaine version.
Encore merci pour vos suggestions. Si vous en avez d'autres, n'hésitez pas.
Réponses
Je ne pense pas qu'il y ai un problème tant que le mécanisme reconstitue les tuiles en avance sur le défilement. Le delegué de UIScrollView reçoit les événements de scrolling au fur et à mesure, non ? Cela permet donc de pré-dessiner les tuiles nécessaires.
Si le dessin allait plus vite que le défilement, alors on n'observerait pas de problème de fluidité actuellement.
À mon avis, on ne peut pas rendre cela beaucoup plus rapide à moins d'accélérer le rendu vectoriel pendant le défilement:
- désactiver l'anti-aliasing (à essayer: simple et efficace)
- désactiver les transparences
- ne pas dessiner les lignes trop fines
etc.
Oui tout à fait.
Je ne savais pas que l'on pouvait désactiver l'anti-aliasing, effectivement à essayer.
Par contre je n'utilise pas (encore) les transparences.
Ne pas dessiner les lignes trop fines, à essayer aussi.
Déjà je remplace les textes trop petits par des rectangles gris.
Les visualisateurs de fichiers DXF utilisent OpenGL, c'est rapide mais moins joli notamment pour le texte.
Avec GLKit de iOS 5, il faudra que je regarde mais OpenGL me semble très compliqué.
Sans avoir réfléchi, 2 remarques : l'encombrement mémoire ? superposition des objets ?
Pour la superposition, il n'y a pas plus de problème qu'en vectoriel. Il suffit d'afficher les bitmaps en respectant la même hiérarchie.
Si chacune fait 200 pixels x 200 pixels, il faut donc 2 bitmaps de 200x200 pixels juste pour 2 lignes !?
En dessinant les 2 bitmaps l'une sur l'autre, le fond de la 2ème va écraser la première ou bien il faut un fond transparent.
Cela est-il possible ?
C'est infiniment plus rapide de tracer ces lignes avec OpenGL !
Moi sur ce genre de projet mon approche serait: qu'est ce qui existe déjà et comment l'améliorer substantiellement sans tout casser.
L'utilisation d'un cache bitmap est d'autant plus efficace que l'objet est complexe. J'aurais donc tendance à porter mon attention tout particulièrement sur le rafraichissement des textes par exemple dans un premier temps.
Le device a ici un espace mémoire limité. Donc je le prendrais aussi en compte pour mon architecture. En partant du prorata de bitmaps avec une couche alpha pour la transparence, le tout avec 8bits par couche, je suis à 4 octets par pixel. Il est facile de mettre en place un petit système de gestion de cache centralisé. Lorsqu'un objet a besoin de se dessiner, il demande au gestionnaire de cache:
- j'ai besoin de 200x200x4 octets. Est-ce ok pour toi?
- Ouai pas de problème j'ai largement ce qu'il te faut.
Sinon il répond non et l'objet se dessine en vectoriel à moins que le gestionnaire de cache face de la place du fait que des objets sont hors champ. Si ok, l'objet informe le gestionnaire de cache (un singleton?) de la mémoire qu'il a utilisé afin que celui-ci en tienne compte et le référence.
Bref c'est pas très lourd à développer et le gain est garanti. C'est ce que je fais tous les jours sur Mac avec Core Animation entre autre.
PS: concernant OpenGL cela devient vite très complexe à gérer et cela sans doute encore plus sur un petit device.
Je ne suis pas certain d'avoir tout bien optimisé mais le résultat n'a pas été concluant.
Vous pouvez télécharger les projets ici :
http://www.adx-online.com/SimpleTiledScrollExample.zip
http://www.adx-online.com/ZoomingPDFViewer.zip
et le fichier iPocket Draw correspondant :
http://www.adx-online.com/TestPage.rcad.zip
Il y a plus de 57000 objets donc là , ça ralentit bien...
J'ai commencé à prendre vos remarques en compte :
- Draken, j'ai mis la StatusBar transparente et en plus je la cache en même temps que l'UI lors de touches;
Cela m'a posé quelques problèmes de décalage de vues mais a priori c'est résolu et cela fonctionne bien.
- Pour la vitesse de scrolling, si certains ont fait des tests sur iPad, vous avez peut-être remarqué que les scrollings sont plus rapides. Cela parce que sur les écrans non Rétina, je bouge la bitmap du dessin et ne redessine que la portion scrollée.
Je n'avais pas finalisée cette procédure sur l'écran Rétina à cause d'un floutage du dessin donc je redessinais tout à chaque fois. En cherchant un peu, j'ai trouvé qu'il faut utiliser "UIGraphicsBeginImageContextWithOptions" pour les écrans Rétina. Maintenant cela fonctionne aussi sur Rétina mais j'ai encore un petit décalage qui apparaà®t de temps en temps à la jonction avec la zone mise à jour.
Vous aurez donc ces nouveautés dans la prochaine version.
Encore merci pour vos suggestions.
Si vous en avez d'autres, n'hésitez pas.
Une nouvelle version vient d'être validée par Apple.
La plupart de vos remarques ont été prises en compte.
Encore merci pour votre aide.
Et si vous avez d'autres suggestions, n'hésitez pas.
La version 1.90 vient d'être validée par Apple.
Grosse nouveauté : la lecture des fichiers DXF.