Witam ostatnio stwierdzilem ze w Javie SDK oraz Androidzie drawCircle jest
dosc kiepsko zaimplementowane, tzn przy duzych okregach jest slaba dokladnosc.
Przy malych okregach wszystko jest w porzadku.
Zalezy mi na okienkowaniu i na szybkiej metodzie rysowania fragmentow okregu.

Przy malych okregach zamierzam rysowac standardowo uzywajac Graphics.drawOval
oraz Canvas.drawCircle bez implementowania okienkowania,
dla duzych okregow chce napisac okienkowanie i rysowanie tak zeby bylo dokladnie i w
miare szybko, jednak szybkosc jest drugorzedna.

Mysle ze to beda przypadki gdy sa widoczne tylko 1 lub 2 oktety okregu.
Sadze ze bedzie trzeba rysowac wykorzystujac drawLine
w Androidzie byc moze warto uzyc drawPath lub drawLines aby zyskac na wydajnosci.

Jakies sugestje ?

do góry

On Wednesday, May 15, 2013 7:04:09 PM UTC+2, Radoslaw Jocz wrote:
> Mysle ze to beda przypadki gdy sa widoczne tylko 1 lub 2 oktety okregu.
>
> Sadze ze bedzie trzeba rysowac wykorzystujac drawLine
>
> w Androidzie byc moze warto uzyc drawPath lub drawLines aby zyskac na wydajnosci.

Zasadnicze pytanie brzmi: dlaczego chcesz to zrobić? (tzn. komu i w
czym niedoskonałości tych bibliotek przeszkadzają) Dodatkowe: ile będzie
okręgów?

w.

do góry

On Wednesday, 15 May 2013 20:59:49 UTC+1, Wojciech Muła wrote:
> On Wednesday, May 15, 2013 7:04:09 PM UTC+2, Radoslaw Jocz wrote:
>
> > Mysle ze to beda przypadki gdy sa widoczne tylko 1 lub 2 oktety okregu.
>
> >
>
> > Sadze ze bedzie trzeba rysowac wykorzystujac drawLine
>
> >
>
> > w Androidzie byc moze warto uzyc drawPath lub drawLines aby zyskac na wydajnosci.
>
>
>
> Zasadnicze pytanie brzmi: dlaczego chcesz to zrobić? (tzn. komu i w
>
> czym niedoskonałości tych bibliotek przeszkadzają) Dodatkowe: ile będzie
>
> okręgów?
>
>
>
> w.

Chce precyzyjnie odwzorowywac figury geometryczne a standardowa funkcja drawCircle
dziala dosc dobrze tylko przy malych okregach. Np przy np promieniu 500 czy 1000 lub
wiekszych, gdy wycinek okregu widoczny na ekranie jest juz tylko lekko zakrzywiona
krzywa to wtedy sa spore bledy. Najeiwksze bledy sa chyba na srodku kazdego z
oktetow. czyli przy katach 1/16 * n, ale musial bym do dokladnie sprawdzic. Ponadto w
Java SDK widzialem efekt przepelnienia int-ow chyba taki ze pozycjonowalo okregi
skokowo.

Nie ma byc wiele okregow, na razie mysle ze kilka np 5 do 10, 20 max w porywach.
Tylko ze powinny byc oblugiwane bez problemowo promienie od 1 do 1 000 000 powiedzmy.
Ale powinno tez dzialac plynnie tzn drag and pinch zoom czyli w sposob user friendly.

do góry

On Wednesday, May 15, 2013 10:30:33 PM UTC+2, Radoslaw Jocz wrote:
> Chce precyzyjnie odwzorowywac figury geometryczne a standardowa funkcja drawCircle
dziala dosc dobrze tylko przy malych okregach. Np przy np promieniu 500 czy 1000 lub
wiekszych, gdy wycinek okregu widoczny na ekranie jest juz tylko lekko zakrzywiona
krzywa to wtedy sa spore bledy. Najeiwksze bledy sa chyba na srodku kazdego z
oktetow. czyli przy katach 1/16 * n, ale musial bym do dokladnie sprawdzic. Ponadto w
Java SDK widzialem efekt przepelnienia int-ow chyba taki ze pozycjonowalo okregi
skokowo.
>
>
>
> Nie ma byc wiele okregow, na razie mysle ze kilka np 5 do 10, 20 max w porywach.
>
> Tylko ze powinny byc oblugiwane bez problemowo promienie od 1 do 1 000 000
powiedzmy. Ale powinno tez dzialac plynnie tzn drag and pinch zoom czyli w sposob
user friendly.

Przy tak małej ilości celowałbym we własny rastryzator. Algorytm
Bresenhama działa poprawnie dla dowolnych promieni i jest banalny
w implementacji.

Inne wyjście, to aproksymować okręgi wielokątami o dużej liczbie
boków, z tym, że ich liczbę musiałbyś jakoś wyznaczać na podstawie
promienia i rozdzielczości. Ale do tego nie kojarzę "gotowca".

w.

do góry

Rozwazam wlasnie sprawe z wielokatami foremnymi. Moja prowizoryczna implementacja
jest obiecujaca.

Wygenerowanie odpowiednich wierzcholkow jest proste. Jednak dochodzi do tego
okienkowanie, Myslalem tez nad Cohen-Sutherland do szybkiego odrzucania
niepotrzebnych bokow.

do góry

Problem z Circle Midpoint - Berzenham jest taki ze putpixel nie dziala w Javie.

do góry

Cohen-Sutherland lub Fast clipping zastosuje do odrzucania odcinkow w danym oktecie
ktory ma byc czesciowo renderowany. Pozostale cwiartki lub oktety mozna odrzucic
przez badanie czesci wspolnej 2 prostokatow.

do góry

W dniu 2013-05-15 19:04, Radoslaw Jocz pisze:
> Witam ostatnio stwierdzilem ze w Javie SDK oraz Androidzie drawCircle jest
> dosc kiepsko zaimplementowane, tzn przy duzych okregach jest slaba dokladnosc.

Na czym polega ta słaba dokładność?
Czyżby nie używali tutułowego midpointa?

> Przy malych okregach wszystko jest w porzadku.
> Zalezy mi na okienkowaniu i na szybkiej metodzie rysowania fragmentow okregu.
>
> Przy malych okregach zamierzam rysowac standardowo uzywajac Graphics.drawOval
> oraz Canvas.drawCircle bez implementowania okienkowania,
> dla duzych okregow chce napisac okienkowanie i rysowanie tak zeby bylo dokladnie i
w miare szybko, jednak szybkosc jest drugorzedna.
>
> Mysle ze to beda przypadki gdy sa widoczne tylko 1 lub 2 oktety okregu.
> Sadze ze bedzie trzeba rysowac wykorzystujac drawLine
> w Androidzie byc moze warto uzyc drawPath lub drawLines aby zyskac na wydajnosci.
>
> Jakies sugestje ?
>

Masz tam krzywe Beziera? Wyznacz parametry krzywej przybliżające
interesujące Cie łuk (już 1/4 okręgu bardzo przyzwoicie
przybliża się jedną krzywą) i niech o resztę zadba algorytm
ryzujący krzywą.

pzdr
bartekltg

do góry

Krzywych Beziera nie musze rysowac.

do góry

On Thursday, 16 May 2013 00:37:50 UTC+1, bartekltg wrote:
> W dniu 2013-05-15 19:04, Radoslaw Jocz pisze: > Witam ostatnio stwierdzilem ze w
Javie SDK oraz Androidzie drawCircle jest > dosc kiepsko zaimplementowane, tzn przy
duzych okregach jest slaba dokladnosc. Na czym polega ta słaba dokładność? Czyżby nie
używali tutułowego midpointa? >

Pewnie uzywaja cos w stylu midpoint ale pojawiaja sie przypadki szczegolne.
Przy duzych promieniach zauwazylem ze pewne obszary okregu maja nieco inny promien.
Zbadalem ten problem dokladniej i wiem ze okregi o duzym promieniu sa nieco
zdeformowane. Przy katach 0, 45, 90, 135 wszystko sie zgadza ale przy np 22.5, 67.5
juz nie. Nie sadze ze wynika to z bledow moich obliczen i bibliotek.
Poprostu wizualizacja okregow jest kiepska.

Mysle ze moze dochodzic do przepelnienia int-ow lub cos innego.
W zarowno w Androidzie jak i na desktopie jest podobnie.

do góry