Tracé de segments Bresenham dépassé ? y'a p-ê plus rapide !! - Page 2

Ce n'est pas moi qui ai commencé...

lol moi je penserais plutôt que si
Mais bon, on s'est assez engueulés dans l'autre topic, si ici on pouvait revenir au sujet

oui, je remets donc le topic en haut de liste

merci

de rien, voyons
tiens, je recommence

merci

sauf qu'en moyenne, un segment n'a que 2/ln(2)=2.9 pixels consécutifs...
à mon humble avis, autant on peut optimiser bresenham à 2x sa vitesse actuelle (ie genlib ou graphlib de teos), autant j'ai l'impression que ta méthode sera peu efficace pour des segments quelconques

2/ln(2)...

comment fais tu cette moyenne..
[edit]Edité par TiMad le 04-01-2002 à 11:32:50[/edit]

les traitements segmentés sont TRES efficaces pour tracer des droites de faible pente en X ou Y ... la diagonale est le pire des cas, à mon avis, si on veut vraiment en tirer le meilleur, il faut switcher entre le bresenham standard et les traitements segmentés en fonction de la gueule de la droite à tracer... pke bresenham est TRES lent (comparativement aux ts) pour tracer des droites à faible pente... en fait, ça ne devient réellement intéressant que pour les grandes droites dont chacun des "steps" fait dans les 8 pixels ou plus...

oui, mais le temps de calculer si on fait classique ou ts, c aussi à prendre en compte

c pour ça que j'ai dit des traitements de 8 pixels ou plus, si le temps pris par les tests étaient nuls, ça ferait moins, mais en en tenant compte, ça doit faire un truc comme ça... (n'empêche que pour en avoir une idée précise, il faudrait faire un bench...)

Pour le determiner, tu fais une moyenne sur l'ensemble des droites du quart de cercle.
Ce qui fait que bien peu de segments sont reellement optimisees.

en gros, c se prendre la tête pour pas grand chose !