eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.comp.programmingcircle midpoint + windowing, reverse, REAKTYWACJAcircle midpoint + windowing, reverse, REAKTYWACJA
  • X-Received: by 10.140.25.138 with SMTP id 10mr68910qgt.41.1444305070724; Thu, 08 Oct
    2015 04:51:10 -0700 (PDT)
    X-Received: by 10.140.25.138 with SMTP id 10mr68910qgt.41.1444305070724; Thu, 08 Oct
    2015 04:51:10 -0700 (PDT)
    Path: news-archive.icm.edu.pl!agh.edu.pl!news.agh.edu.pl!news.cyf-kr.edu.pl!news.nask
    .pl!news.nask.org.pl!newsfeed.pionier.net.pl!news.glorb.com!z77no8310297qge.1!n
    ews-out.google.com!68ni54570qgg.0!nntp.google.com!z77no8310295qge.1!postnews.go
    ogle.com!glegroupsg2000goo.googlegroups.com!not-for-mail
    Newsgroups: pl.comp.programming
    Date: Thu, 8 Oct 2015 04:51:10 -0700 (PDT)
    Complaints-To: g...@g...com
    Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=80.4.98.181;
    posting-account=ep55TgoAAAD3FPdT4j2MbhszjClpO1MM
    NNTP-Posting-Host: 80.4.98.181
    User-Agent: G2/1.0
    MIME-Version: 1.0
    Message-ID: <f...@g...com>
    Subject: circle midpoint + windowing, reverse, REAKTYWACJA
    From: Radoslaw Jocz <r...@g...com>
    Injection-Date: Thu, 08 Oct 2015 11:51:10 +0000
    Content-Type: text/plain; charset=ISO-8859-2
    Content-Transfer-Encoding: quoted-printable
    Xref: news-archive.icm.edu.pl pl.comp.programming:208440
    [ ukryj nagłówki ]

    witam,
    jakiś czas temu zaimplementowałem okienkowanie i rysowanie okręgu o dużym promieniu,
    którego nie obsługuje poprawnie standardowe API,
    conajmniej Java SDK oraz API Javy w Androidzie, sadzę że w przypadku wielu innych API
    w innych językach jest podobnie.

    Przypomnę interesują mnie przypadki rysowania wycinku łuku i jego okienkowania.
    Opracowałem sprawny algorytm ustalania które ćwiartki należy rysować, które z nich w
    pelni a które tylko częściowo. Samo rysowanie odbywa się juz w oktetach,
    (ćwiarki są dzielona na pół).

    Czasami pojawiają się drobne problemy ze zgraniem pikseli, czyli w pewnych
    przypadkach wystepuje maksymalnie blad o 1 piksel. Widoczne to jest przy kacie 45
    stopni.

    Błąd wynika z pozycjonowania oktetu a nie ze sposobu jego rysowania.
    Z racji tego że punkty startowe sa wyliczane jako double a orginalny midpoint jest
    int więc w tym musiał bym szukać problemu. Sama juz procedura rysowania jest bardzo
    podobna do midpoint.

    Moim zdaniem najlepszym doraźnym rozwiazaniem problem było by rysowanie
    okretów w przeciwnym kierunku niż to ma miejsce w orginalnym midpoincie.
    Obliczenie punktu przy kącie 45 stopni polegało by na przemnozeniu raduisa
    przez stałą. Oktety korzystały by z tych samych danych początkowych więc musiały by
    być idealnie dopasowane i symetryczne.

    Ponadto takie podejście jest bardziej korzystne jeśli chcemy rysować to co widoczne
    jest wewnątrz okna, bo okno obcina gore-dol-lewo-prawi zostawiając
    fragment koła pomiędzy, więc często obszary przy kącie 45 stopni są widoczne.

    Macie jakieś pomysły jak odwrócić prodecure midpoint,
    aby działała w przeciwnym kierunku?

    Nie jestem pewien czy ze punktem wyjścia do opracowania mojej prodecury była by
    orginalna procedura midpoint czy ta zoptymalizowana.



Podziel się

Poleć ten post znajomemu poleć

Wydrukuj ten post drukuj


Następne wpisy z tego wątku

Najnowsze wątki z tej grupy


Najnowsze wątki

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: