Vitesse Maximale pour afficher un pixel
Bonjour tout le monde
s'il vous plais je souhaite connaitre la vitesse maximal réalisable peu importe le lagunage de programmation pour afficher un pixel sur l'écran du pc.
supposant un écran qui fait 1024 x 768 pixels, pour que je balaye tout les pixels un par un en mode VGA. je veux dire par balayer, convertir la couleur du pixel du noir au blanc.
a votre avis avec l'API le plus optimisé pour ce type de fonctions quelle la vitesse maximal atteignable ?
Merci !
celui du balayage de l'écran (50hz, 60hz, 100 hz, ...) selon l'écran pour que ce soit visible (mais l'image peut être calculer plus souvent)
quel est le but ? le plus rapide serait sans doute du C/langage machine.
Bonjour,
En complément de umfred, une bibliothèque qui me semble raisonnablement performante est OpenGL (en C). Ensuite (outre l'écran), les performances dépendent de la présence ou non d'une carte graphique (et de son type) ainsi de ce que l'on souhaites faire: afficher simplement des pixels noirs/blancs est beaucoup moins demandeur en temps calculs que le raytracing d'une scène en 3D.
bonsoir,
pas clair car l'affichage proprement dit est réalisé en hard et c'est figé une fois le format d'image défini, par contre la modification de l'image est tributaire de la machine graphique utilisée ce qui implique CPU/ GPU et logiciel.
Mais au final rien ne sert de calculer plus vite que ce que l'automate peut afficher.
JR
l'électronique c'est pas du vaudou!
Dans certains vieux benchmark, on peut dépasser les 1000 images par seconde pour afficher des images complexes avec les PC modernes, mais bien sûr l'écran est incapable de l'afficher.
Du coup, pour afficher une image unie, ça doit être beaucoup plus rapide.
Re : Vitesse Maximale pour afficher un pixel
Re bonjour et merci beaucoup pour vos réponses.
Je repose ma question mais autrement, car je sens qu'on se rapproche de la bonne réponse
Suposant un écran de taille 1024 x 730 pixels
Ce qui fait 747520 pixels au total (physiques)
Supposant maintenant que j'ai cet exacte nombre,... mais d'images !!
747520 images (bmp monchrome) de taille 1012 x 730 chacc'une numerotées de 1 jusqu'à 747520
Sur chaque image tout les pixels sont Noires sauf 1 à chque fois est Blanc mais sa9 position est differente des autres.( incrémentée à chaque fois )
En faisant défiler ces images ( à petite vitesse ) l'utilisateur vairra sur l'écran un balayage d'un pixel blanc sur un fond noire du coin haut gauche de l'écrant jusqu'au coint bas droit de ce dernier.
Avec un delais de t =10 ms entre chaque affichage le temps total est éstimé à 2 heures et quelques minutes.
Ma question maintenant ...!!
Jusqu'à quelle valleur pourrai-je diminuer le temp "t" entre image et image mais à condition à ce que je récupère un vrais balayage de pixel sur mon écran ?
Autrement dit.. si j'arrive par exemple ( je dis n'importe quoi...hen..) à rendre t = 1 us
Et que les images défillent toutes et je j'enregistre ce défillement avec une caméra à très haute vitesse de capture ( 2000 fps) , obtiendrai-je à la fin une video où chaque pixel est affiché clais est séparement ?
Excusez moi le but de mon algorithme n'est pas claire car l'idée est plus grande que ça et je ne veux pas vous distraire avec trop de détails, j'ai essayé de cerner l'handicap actuel, une fois la bonne réponse trouvée on pourra discuter d'avantge et comme ça vous saurrez le but final.
Selon certaines de vos réponses je sens que cela va être difficile car à un certain moment le cpu ou gpu pourront travailler à une vitesse plus grande que celle du processeur d'images integré dans l'écrant lcd.
Autrement dit le gpu poura calculer et préparer ces image dans un temps record mais sera toujour retardé par la vitesse d'affichage de l'écran...c'est ça ou je n'est pas bien compris ?
Merci à tous
À vous....
a priori, ce qui va te limiter c'est alors le taux de rafraichissement de l'écran (sa fréquence de balayage) donc les fameux 50/60/../240hz (le max aujourd'hui je crois) (et il faut que la carte graphique suive aussi)
Maintenant on veut connaitre le but final.
Le mélange de vrai et de faux est énormément plus toxique que le faux pur - Paul Valéry
bonjour,
vu la complexité de l'image c'est bien l’écran qui limitera.
JR
l'électronique c'est pas du vaudou!
Bonjour,
En effet, je pense qu'un simple "shader"* devrait pouvoir effectuer la tâche demandée sans même explicitement mettre une image en mémoire.Envoyé par jiherve
*https://fr.wikipedia.org/wiki/Shader
bonsoir,
meme un µC est capable de changer la couleur de 2 pixels en moins de qqs µS!
JR
l'électronique c'est pas du vaudou!
Pas du tout familier avec le concept, mais très interessé par l'idée !!
Je ferai une recherche en ce propos...des me proposer quelques liens sera très apprecié
Merci encore !!!
Ce n'est pas bête non plus.... mais je pense que pour pouvoir le réaliser je deverai disposer d'un datasheet très détaillé de mon ecran lcd ..chose qu'on ne trouve pas facillement sur le net
Les gars vous résurecter l'espoire en moi avec vos suggestion car pour un instant j'ai commencer à desesperer...
Car d'après une logique simple je suis sûre l'écran LCD est capable de permuter la polarité de ces pixels à une vitesse en ordre de uS mais l'handicape et le controlleur VGA je pense qui limite le délais de raffrechissement en 60 Hz ou autres...
Si il y a moyen même de réaliser ça avec un simple micro contolleur et un afficheur LCD je suis ouvert à toutes proposition...
Vous avez compris mon but...balayage simple et pour un pixel unique sur l'écran à la vitesse maximal atteignable.
Merci beaucoup pour vos réponses
Bonjour,
Si cela vous intéresse, voici un tutoriel OpenGL en français: http://www.opengl-tutorial.org/fr/be...ning-a-window/. Cela demande un peu d'investissement, mais on peut rapidement obtenir des choses assez "sympa".
Tout à fait daccord avec vous mais en lisant des passage sur le tutoriel j'ai vu que c'est un moteur d'affichage graphique qui optimise les calcules complex avant affichage ce qui rend au finale l'affichage des rendu les plus complex plus fluide pour l'utilisateur. Mais....mais ...MAIS !!
Je pense que nos amis ont raison concernant la lipitation du taux de rafrechissement de l'écran.
Ce que je cherche moi est un affichage mono pixel mais sur le hard...directement sur l'ecran...1 pixel à la fois .. ça se vois bête mais c'est un nesoin promordial pour une application plus complex..
Acctuellement j'ai trouvé que le taux de raffreshissement le plus rapide du marcher et dans les 240 Hz....240 affichage par seconde max !!!
C'est trop peu comme vitesse si je veux ballayer 1024 x 730 pixel en moins de 2 secondes..
À part si j'attaque le LCD directement à l'aide d' un micro controlleur comme notre ami l'a mentionné plus haut... mais pour le faire..j'irai par récurance..
Je dois trouvé une datasheet bien détaillée pour un LCD plus j'acheterai ce dernier.
De toute façon, les LCD ont un temps de réaction au mieux de 1ms, soit 1000Hz, même en contrôlant directement l'écran, tu n'arriveras à faire ton balayage en moins de 2s, ou sinon, tu peux t'attendre à avoir plusieurs pixels allumés en même temps.
Une solution pour ton problème, c'est un bon vieux tube cathodique.
