Java zeichnet linien nicht korrekt?

[Xtian]

Also ich hab grad mit drawPolygon ne Linie gezeichnet (Steigung -0.5 ) und ich finde java Zeichnet die linie falsch. Im Anhang hab ich ne kleine Datei angehängt. Die Pinke linie Zeichnet Java und meiner Meinung nach sollte die linie eher wie die Rote linie aussehen die ich per Grafikprogramm dazugezeichnet habe. Weiß jemand wie ich die linie eher so wie die rote hinbekommen könnte?

 

[SlaterB]

das ist aber wirklich ein kleiner Ausschnitt,
gerade am linken und rechten Rand siehts ja ganz anders aus, da geht's links senkrecht nach oben und rechts fast waagerecht weiter + senkrecht nach oben,
wieso ist eigentlich das Grau so unregelmäßig, ist das vielleicht eine JPEG-Speicherung, die mal eben alles bisschen unsauber durcheinanderwirft?

also ich weiß noch nicht wirklich sinnvoll weiter, aber bisschen größeres Bild wäre wünschenswert, mit vielleicht 20 Stufen und nicht nur 4-5,
die Linien nicht so dicht zusammen, einheitlicher Hintergrund, keine Senkrecht-Linien,
auch ne 45 Grad-Treppe, diese ist doch 60 Grad bzw. 30 Grad

evtl. etwas Code

 

[0x7F800000]

wieso interessieren dich überhaupt diese hässlichen pixeltreppen... Zeichne es doch gleich "exakt" mit antialiasing, da musst du doch nur ein Flag umschalten, und schon sieht es so genau wie irgendwie möglich aus.

 

[Xtian]

also die linie ist eben nur so groß. 14*7 pixel. deswegen hab ich gleich alles vergrößert. der Hintergrund ist so unregelmäßig da dies ein bild hintendran ist. das liegt schon vor der zeichenoperation in meinem Graphics2D objejt aber daran kann das ja nicht liegen. Und die linie muss so sein. Also nichts mit antialising.

Und es ist halt das problem dass die linie eben genau so sein muss es würde mir nichts bringen dass die im 60 grad winkel oder länger oder so wäre. und es wäre echt wichtig dass sie exakt ist.

Achja: die sekrechten linien am Rand gehören zum rest des Polygons. Anfangs und endpunkte der linien hab ich etwas dunkler markiert

 

[hdi]

Also mich interessiert das auch. Falls Java wirklich nicht "sauber" zeichnet, wäre das
ja schon gut zu wissen. Und noch besser, wie man das fixen kann.

AntiAliasing hat damit ja eigentlich nichts zu tun, das verändert die Position der Pixel ja nicht
sondern mal nur ähnlichfabrige Pixel drumrum.

Also ich bin bitte auch für ein neues, grösseres Bild in einem verlustfreierem Format.

 

[SlaterB]

poste Bildvorlage(-ausschnitt) und Code(-ausschnitt (auch zum Einlesen des Bildes ))

 

[0x7F800000]

AntiAliasing hat damit ja eigentlich nichts zu tun, das verändert die Position der Pixel ja nicht
sondern mal nur ähnlichfabrige Pixel drumrum.

Nja, eigentlich sieht das auf dem bild wirklich eher so aus, als ob das ein Bogenstück oder irgendeine Bezierkurve wäre, es sieht überhaupt nicht nach einer geraden aus.

Wenn kein Code, dann will ich zumindest mal ein paar von koordinaten kennen: von wo nach wo muss ich drawLine() aufrufen, damit solcher Schrott rauskommt ???:L

Ne, moment, ich bin ja nicht faul, ich kann auch die Pixel nachzählen^^
(0,0) nach (14,7) oder so? So um +-1 ist's richtig, ich probier's grad aus...

 

[hdi]

wir dürfen auch nicht vergessen:

er hat die linie per drawPolygon() gemalt, nicht per drawLine. Theoretisch sollte
das ja keinen Unterschied machen, aber wer weiss.

 

[Xtian]

den code... naja das würde nicht viel nützen denn die punkte in draw polygon kann man nicht recht nachvollziehen. End und Startpunkt der betroffenen linie Stimmen ja.
Hintergrundbild ist schon generiert... das heißt ich kann bloß nen bildausschnitt aus nem screenshot schicken. Wegen dem linienbild. Das ist ja 2000%ig vergrößert abgespeichert... als mit jpeg hat das denke ich eher weniger zu tun

also als anhnag mal en bildausschnitt

nur dass man auch mal sieht: da sind ja viele solcher linien... jede einzelne hat dieses problem... gut hier braucht man wohl ne bildschirmlupe xD

 

[hdi]

denn die punkte in draw polygon kann man nicht recht nachvollziehen

genau das solltest du aber mal machen.
Lass dir doch vom Polygon direkt vor dem Zeichnen die Punkte ausgeben.
Wenn du nicht weisst, was du da machst, wer denn dann?

 

[0x7F800000]

Also, folgender code:
[highlight=Java]
g.setColor(Color.WHITE);
g.fillRect(0,0,50,50);
g.setColor(Color.BLACK);
g.drawLine(10,10,23,16);
[/highlight]
generiert folgende schwarze linie:

Imho sollte sie genau so aussehen.
Das rot eingezeichnete aus deinem ersten bild sieht auch genauso aus.
=> An primitiven zeichenroutinen wird's nicht liegen

Statt hier weiter rumzurätseln, solltest du das Problem isolieren, und hier den minimalen beispielcode posten.
Zum thema rumrätseln: wenn das polygon von irgendeinem selbstgebastelten Kantenerkennungsalgo kommt, dann kann es sein, dass er alles in 2px große Stücke zertrümmert hat, und das, was eine einzelne linie sein sollte, besteht jetzt stattdessen aus 20 krumm zusammengeklebten einzelstücken.

Aber da du nichts konkretes bisher erzählt hast, ist das wirklich reine Phantasie... :autsch:
Beim zu zeichnenden polygon kannst du doch alle Punkte einzeln durchgehen, und koordinaten jeweils ausgeben lassen, wieso machst du es nicht einfach mal?

 

[Xtian]

ich mein an den koordinaten liegts ja nicht. Denn wie gesagt anfangs und endpunkt stimmen. Ich mein ich könnte sie trotzdem ausgeben aber wär sinnlos. was ich jetzt mache ist mein JRE updaten.

gut aber hier mal code... nicht lachen

int xv = i * -14 + j * 14 + 1600
	- (gebXpos * -14 + gebYpos * 14 + 1600 - 126);
int yv = i* 7+ j* 7- fm.gibAngezeigteHöhe(i + 1, j)- (gebXpos * 7 + gebYpos * 7
	- fm.gibAngezeigteHöhe(gebXpos, gebYpos) - 153);
Polygon p = new Polygon(new int[]{xv + 14, xv + 27, xv + 27,
			                        xv + 14, xv + 14}, new int[]{yv + 12, yv + 6, yv + 5 - diff,
						yv + 11 - diff, yv + 12}, 5);
tmp.drawPolygon(p);

 

[0x7F800000]

gut aber hier mal code... nicht lachen

int xv = i * -14 + j * 14 + 1600
    - (gebXpos * -14 + gebYpos * 14 + 1600 - 126);
int yv = i* 7+ j* 7- fm.gibAngezeigteHöhe(i + 1, j)- (gebXpos * 7 + gebYpos * 7
    - fm.gibAngezeigteHöhe(gebXpos, gebYpos) - 153);
Polygon p = new Polygon(new int[]{xv + 14, xv + 27, xv + 27,
                                    xv + 14, xv + 14}, new int[]{yv + 12, yv + 6, yv + 5 - diff,
                        yv + 11 - diff, yv + 12}, 5);
tmp.drawPolygon(p);

Worüber genau soll ich da lachen? Darüber dass du in einem beispiel mit vier zeilen code 9 unbekannte Variablen, mindestens eine unbekannten Klasse und eine unbekannten methode verwendet hast? Was sollen wir denn damit bitte anfangen? :noe:
"gib"- sowie der ganze andere "deutschsprachige" kram ist auch eher zum heulen (na gut, das lässt sich *einigermaßen schnell* mit einer ide refactorn, aber wieso soll man sich das antun? egal, das ist eh offtopic...)

Wir warten dann mal weiter auf irgendwas kompilierbares wo das genannte problem auftritt... Neue JRE runterzuladen wird da wohl nicht viel bringen, das alles ist seit Jahren alles unverändert geblieben.

 

[Marco13]

Sag' das nicht - da hat sich einiges getan... neulich bin ich über Bug ID: 4151279 Curves are not as pleasing as JDK 1.1 (affects ovals, arcs and roundrects) gestolpert (siehe auch die related bugs). OK - dass sich da seit Jahren nichts geändert hat, stimmt in gewisser Hinsicht doch - siehe einer der letzten Kommentare: "It took 7 years and 3 months to fix this bug!..."

EDIT: Ein Tag korrigiert, und gleich noch den Kommentar hinterher: Das hier bezog sich auf Polygone (und der Bug nicht) aber einige ähnliche/related Bugs kritisieren allgemeine Ungenauigkeiten beim Zeichnen....

 

[Xtian]

tja das mit dem deutschsprachigen... ich denke dir steht nicht zu das zu kritisieren. Das ist eben Programmierstil. Und für mein Fall reichts. Das ist genauso egal wie ob man die geschweifte offene Klammer hintder oder unter den Methodenkopf setzt.

gut wie die xv und yv zustande kommen hätte ich nicht unbedingt reinbringen müssen. und aus dem rest kann man herauslesen - zumindest wenn man sich ein bisschen mühe gibt - dass das verhältnis der punkte für die linie stimmt. Aber ich hab ja gesagt mit meinem Code hierfür kann keiner was anfangen.

 

[Marco13]

Nicht ganz. Ich erinnere mich an ein hochinteressantes Programm, das ich mal gelesen habe ... mit ausführlichen Kommentaren ... auf spanisch :autsch: ... es gibt http://java.sun.com/docs/codeconv/html/CodeConventions.doc8.html#367 und spätestens wenn man irgendwelchen Bean-Fressern beibringen muss, dass es zum eigenen Stil gehört, "gib" statt "get" zu schreiben, kommt die Erleuchtung.

Aber es stimmt natürlich: Für sich selbst kann jeder das so machen, wie er will.
Wann man dann Zeit, Lust oder einen Anlass hat, sich mühsam umzugewöhnen, kann Außenstehenden ja egal sein.

Aber ich hab ja gesagt mit meinem Code hierfür kann keiner was anfangen.

Keiner ... ? Nicht gut :bae:

 

[hdi]

Zerleg mal das erstellen des Polyongs und das Berechnen der Koordinaten.

Mach dir 5 Point-Objekte, lass dir (und uns) danach diese Points ausprinten, und
bau dir dann danach damit ein Polygon.

So wie der Code im Moment ist kann/will sich das doch keiner vorstellen.

 

[0x7F800000]

Sag' das nicht - da hat sich einiges getan... neulich bin ich über Bug ID: 4151279 Curves are not as pleasing as JDK 1.1 (affects ovals, arcs and roundrects) gestolpert (siehe auch die related bugs). OK - dass sich da seit Jahren nichts geändert hat, stimmt in gewisser Hinsicht doch - siehe einer der letzten Kommentare: "It took 7 years and 3 months to fix this bug!..."

EDIT: Ein Tag korrigiert, und gleich noch den Kommentar hinterher: Das hier bezog sich auf Polygone (und der Bug nicht) aber einige ähnliche/related Bugs kritisieren allgemeine Ungenauigkeiten beim Zeichnen....

Holy crap
Wieviel Zeit das genommen hat, ist beängstigend.
Hab eben ein paar kreise mit Java2D gezeichnet, sieht wirklich verdächtig aus:

Aber, um ehrlich zu sein: obwohl das ein ausschnitt aus einem Plot für ein "mathematisch möglichst exaktes" Programm sein soll, ist mir das sowas von egal :gaen:Mit der hand könnte ich das auch nicht wesentlich besser malen. Zumindest nicht so schnell^^:bahnhof: => shit on it? Vielleicht haben sich diejenigen, die den Bug fixen sollten, sich dasselbe 7 Jahre lang gedacht...

Edit: [bzgl Konventionen]

und spätestens wenn man irgendwelchen Bean-Fressern beibringen muss, dass es zum eigenen Stil gehört, "gib" statt "get" zu schreiben, kommt die Erleuchtung

Neee, das ist viel zu spät. Mit "gib" statt "get" fällt man sehr viel früher auf die Fresse. Bereits wenn man einfach nur mit einer IDE die getter und setter automatisch erstellen lassen will, muss man schon anfangen herumzukonfigurieren (ich will gar nicht wissen, wie und wo bei eclipse sowas gehen soll). Wenn man dann eine derartige Klasse automatisch wrappen lassen will, wird's noch eckliger :noe:

 

[Xtian]

ist nicht so dass ich es nur so machen würde ;-) Sobald eigentlich teile des Programms für andere oder gerade unbekannte bestimmt sind da greife ich schon auf Englische Objekt und methodennamen zurück. Aber gut... offtopic.

okay also zumindest wird das polygon an anderer stelle korrekt generiert. jetzt bin ich richtig ratlos

also wer will so schwer ist das nicht sich da selbst was zu kompilieren... einfach xv und yv (die verschiebung im g2d objekt) irgendwleche ganzzahlen zuweisen und bei diff die höhe des poligons in pixel >0 aber wie gesagt an anderer stelle funktionierts korrekt... sch...eibenkleister

 

[Xtian]

okay ich denke ich habs gelöst.

mit

tmp.setColor(new Color(0xffffff));

statt

tmp.setColor(new Color(0xaaff00ee, true));

funktioniert es. Daher vermute ich dass es am Alpha Kanal liegt. Ist auch egal. Solange es Klappt

 

[hdi]

Neee, das ist viel zu spät. Mit "gib" statt "get" fällt man sehr viel früher auf die Fresse. Bereits wenn man einfach nur mit einer IDE die getter und setter automatisch erstellen lassen will

Also als Anwender der Klasse würde ich noch früher auf die Fresse fallen, und zwar
wenn ich in Eclipse .get (Strg+Space) eingebe, und keinen Getter für den Wert sehe.
Das heisst für mich -> gibt's nich, kack Klasse, kack Menschheit, ziiipp ^^

 

[0x7F800000]

Ist auch egal. Solange es Klappt

Hehe. Vielleicht wirst du damit durchkommen
Aber wenn man so vorgeht, geht man die gefahr ein, den bug noch schwerer ausffindbar zu machen, ohne den zu fixen. Solange er relativ auf der Oberfläche rumkriecht, sollte man den verfolgen und killen.

 

[Xtian]

ja aber ich weiß dann echt nichtmehr woran es sonst liegen könnte... klar ich könnte mal schauen ob die linie an anderer stelle mit diesem halbtransparenten rosa auch krumm wird. aber wenn das so wäre könnte ich wirklich nur noch sagen dass der fehler bei den zeichenoperationen von java liegt.