NOWY TEMAT
elektroda NewsGroups Forum Index - Elektronika Polska - Optymalna struktura dla prostego GUI na mikrokontrolery z wyświetlaczem dotykowym
Konop
Guest
Guest
Wed Dec 29, 2010 2:32 pm
Witam
Ma ktoś jakieś doświadczenie w pisaniu *prostego* GUI dla
mikrokontrolerów z wyświetlaczem dotykowym monochromatycznym?
Potrzebuję zrobić coś takiego (rysowanie przycisków, okienek, bitmap
itp) na podstawie istniejących funkcji (linia, bitmapa, tekst) no i
nie wiem, w jakiej strukturze najlepiej to zorganizować, żeby łatwo
było to wyświetlać, tworzyć jak i obsługiwać ("kliknięcie")? System
pracuje pod FreeRTOS'em, piszę w C. Trzeba zapewne stworzyć listę
obiektów, np. w kolejności rysowania... Ale jak to zrobić, żeby się
później nie narobić?? Problemy które widzę, to:
-elementy są różnego typu, każdy posiada inne cechy szczególne...
-trzeba jakość obsłużyć "klikanie" na element, a różne elementy są
obsługiwane przez różne wątki...
-nie wiem, czy przydatna nie byłaby pewna hierarchiczność zaszyta w
tej strukturze (możliwość usunięcia, przesunięcia, ukrycia całej grupy
elementów).
Ja to widzę tak - tworzę listę elementów, każdy element opisuje:
- położenie i rozmiar (X,Y,W,H)
- typ obiektu (bitmapa, tekst, przycisk...)
- wskaźnik na kolejkę (queue), do której należy wysłać informację np.
o kliknięciu na dany element
- wskaźnik do dodatkowych ifnformacji o danym elemencie...
- wskaźnik na następny element
Tylko, że nie wiem, czy to najlepsze wyjście... może lepiej to trochę
pozmieniać? Może mniej danych wystarczy, może przyda się więcej?? Wolę
sobie wcześniej zaprojektować taką strukturę, niż potem wszystko robić
trzykrotnie... Bo się okażę, że czegoś nie przewidziałem, że apetyt
rośnie w czasie jedzenia itp itd...
Będę wdzięczny za wszelkie uwagi do mojego pomysłu
.
Pozdrawiam
Konop
Robert Zemla
Guest
Guest
Wed Dec 29, 2010 2:32 pm
W dniu 2010-12-29 13:32, Konop pisze:
Quote:
Będę wdzięczny za wszelkie uwagi do mojego pomysłu
.
Pozdrawiam
Konop
Ja zrealizowałem to w taki sposób:
Całość podzieliłem na wirtualne ekrany. W strukturze między innymi mam
zapisane takie parametry jak położenie, wielkość, parametr czy ekran
jest widoczny, wskaźnik kolejki komunikatów/zdarzeń oraz kolejną tablicę
struktur która opisuje konkretne kontrolki na tym ekranie. W strukturze
kontrolek mam to piszesz plus wskaźniki konkretnych funkcji
odpowiedzialnych za rysowanie, rysowanie po kliknięciu itd. Dzięki temu
struktura jest uniwersalna i zawsze taka sama dla różnych typów
kontrolek. Każdy ekran to osobny wątek i osobna kolejka komunikatów. Do
tego stworzyłem szereg funkcji typu: CreateScreen, ShowScreen,
HideScreen, CreateButton, CreateBitmap itd... Nie wiem czy to najlepsze
rozwiązanie w każdym razie działa i nie jest upierdliwe jak trzeba dodać
coś nowego.
pozdrawiam
Sylwester Łazar
Guest
Guest
Wed Dec 29, 2010 2:32 pm
"Ja to widzę tak - tworzę listę elementów, każdy element opisuje:
- położenie i rozmiar (X,Y,W,H)
- typ obiektu (bitmapa, tekst, przycisk...)
- wskaźnik na kolejkę (queue), do której należy wysłać informację np.
o kliknięciu na dany element
- wskaźnik do dodatkowych ifnformacji o danym elemencie...
- wskaźnik na następny element
Tylko, że nie wiem, czy to najlepsze wyjście... może lepiej to trochę"
Ja nie rozumiem, po co stosować takie objekty?
Przypomina to Windows, który od 20 lat "ładuje się",
każdego dnia po kolei, często widać jak pojawiają się w rządku te same
ikony.
Raz na 2 miesiące jakąś dodam, a może raz na tydzień jakaś mi się przesunie
przez pomyłkę.
Pamiętam kiedyś przeniosłem z pół pulpitu do katalogu "stare" :-)
Dlaczego komputer po każdym włączeniu nie może wyswietlić bitmapy z
ostatniego dnia
lub obrazu startowego w postaci panelu użytkowego, a nie reklamy,
ale musi po kolei coś uruchamiać?
Potem dorobić obsługę naciśnięcia [X;Y] i porównać ją z zakresem dostępnych
w danej chwili działań.
Ja tak bym napisał.
--
pozdrawiam
Sylwester Łazar
http://www.alpro.pl
http://www.rimu.pl -oprogramowanie do edycji schematów
i projektowania PCB
WoW
Guest
Guest
Wed Dec 29, 2010 3:16 pm
http://www.linuxfordevices.com/c/a/Linux-For-Devices-Articles/Embedded-
Linux-Graphics-Quick-Reference-Guide/
cos znajdziesz, jest od wxWidgets po podełko zapałek czy GPE
brak
Guest
Guest
Wed Dec 29, 2010 3:22 pm
Konop wrote:
Quote:
Witam
Ma ktoś jakieś doświadczenie w pisaniu *prostego* GUI dla
mikrokontrolerów z wyświetlaczem dotykowym monochromatycznym?
Watpie, zasadniczo to widze dwie drogi :
Ma ktoś jakieś doświadczenie w pisaniu *prostego* GUI dla
mikrokontrolerów z wyświetlaczem dotykowym monochromatycznym?
Watpie, zasadniczo to widze dwie drogi :
1. Jak w poscie ponizej - statyczny obrazek w postaci mapy bitowej oraz
napisane z palca psedo-widgety typu np. 3 cyfry w stalym miejscu ( nie ma
mowy o zadnych oknach a tym bardziej historiach typu mysz, przesuwanie
okien czy zdarzenia).
2. Uzycie istniejacego mikro-GUI - patrz ponizej.
Quote:
Potrzebuję zrobić coś takiego (rysowanie przycisków, okienek, bitmap
itp) na podstawie istniejących funkcji (linia, bitmapa, tekst) no i
nie wiem, w jakiej strukturze najlepiej to zorganizować, żeby łatwo
było to wyświetlać, tworzyć jak i obsługiwać ("kliknięcie")? System
pracuje pod FreeRTOS'em, piszę w C. Trzeba zapewne stworzyć listę
obiektów, np. w kolejności rysowania... Ale jak to zrobić, żeby się
później nie narobić?? Problemy które widzę, to:
-elementy są różnego typu, każdy posiada inne cechy szczególne...
-trzeba jakość obsłużyć "klikanie" na element, a różne elementy są
obsługiwane przez różne wątki...
-nie wiem, czy przydatna nie byłaby pewna hierarchiczność zaszyta w
tej strukturze (możliwość usunięcia, przesunięcia, ukrycia całej grupy
elementów).
Ja to widzę tak - tworzę listę elementów, każdy element opisuje:
- położenie i rozmiar (X,Y,W,H)
- typ obiektu (bitmapa, tekst, przycisk...)
- wskaźnik na kolejkę (queue), do której należy wysłać informację np.
o kliknięciu na dany element
- wskaźnik do dodatkowych ifnformacji o danym elemencie...
- wskaźnik na następny element
Tylko, że nie wiem, czy to najlepsze wyjście... może lepiej to trochę
pozmieniać? Może mniej danych wystarczy, może przyda się więcej?? Wolę
sobie wcześniej zaprojektować taką strukturę, niż potem wszystko robić
trzykrotnie... Bo się okażę, że czegoś nie przewidziałem, że apetyt
rośnie w czasie jedzenia itp itd...
Będę wdzięczny za wszelkie uwagi do mojego pomysłu.
Po lekturze powyzszych wymagan moge stwierdzic iz to "proste" GUI w
itp) na podstawie istniejących funkcji (linia, bitmapa, tekst) no i
nie wiem, w jakiej strukturze najlepiej to zorganizować, żeby łatwo
było to wyświetlać, tworzyć jak i obsługiwać ("kliknięcie")? System
pracuje pod FreeRTOS'em, piszę w C. Trzeba zapewne stworzyć listę
obiektów, np. w kolejności rysowania... Ale jak to zrobić, żeby się
później nie narobić?? Problemy które widzę, to:
-elementy są różnego typu, każdy posiada inne cechy szczególne...
-trzeba jakość obsłużyć "klikanie" na element, a różne elementy są
obsługiwane przez różne wątki...
-nie wiem, czy przydatna nie byłaby pewna hierarchiczność zaszyta w
tej strukturze (możliwość usunięcia, przesunięcia, ukrycia całej grupy
elementów).
Ja to widzę tak - tworzę listę elementów, każdy element opisuje:
- położenie i rozmiar (X,Y,W,H)
- typ obiektu (bitmapa, tekst, przycisk...)
- wskaźnik na kolejkę (queue), do której należy wysłać informację np.
o kliknięciu na dany element
- wskaźnik do dodatkowych ifnformacji o danym elemencie...
- wskaźnik na następny element
Tylko, że nie wiem, czy to najlepsze wyjście... może lepiej to trochę
pozmieniać? Może mniej danych wystarczy, może przyda się więcej?? Wolę
sobie wcześniej zaprojektować taką strukturę, niż potem wszystko robić
trzykrotnie... Bo się okażę, że czegoś nie przewidziałem, że apetyt
rośnie w czasie jedzenia itp itd...
Będę wdzięczny za wszelkie uwagi do mojego pomysłu
.
Po lekturze powyzszych wymagan moge stwierdzic iz to "proste" GUI w
implemntacji bedzie calkiem rozbudowanym projektem.
Zasadniczo w takej systuacji polecam wykorzystanie istniejacego tworu lub
chociaz spojrzenie pt. "Jak to robia inni" aby uniknac wywazania otwartych
drzwi.
Jakis czas temu poszukiwalem jakiegos embedded GUI i z projektow open source
jak na razie znalazlem tylko Nano-X -> http://www.microwindows.org/ ale
obawiam sie iz port dla FreeRTOS'a bedzie wyzwaniem - jest on oparty o
architekture klient-serwer co powoduje iz komunikacja odbywa sie przez
sockety BSD na localhostcie
Z komercyjnych ciekawie wyglada C/PEG ->
http://swellsoftware.com/products/cpeg.php aczkolwiek tez ne ma portu dla
FreeRTOS'a.
Polecam tez spojrzec na GUI systemiku Contiki -> http://www.sics.se/contiki/
oraz biblioteke graficzna PW dla wyswietlaczy monochromatycznych ->
http://sourceforge.net/projects/pwlib/ (jest on blizsza "podejsciu
mikrokontrolerowemu" niz Nano-X).
Zbych
Guest
Guest
Wed Dec 29, 2010 4:18 pm
W dniu 2010-12-29 13:32, Konop pisze:
Quote:
Będę wdzięczny za wszelkie uwagi do mojego pomysłu .
.
Rzuć okiem na bibliotekę microchipa
http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2680&dDocName=en543091
Konop
Guest
Guest
Wed Dec 29, 2010 4:55 pm
Quote:
Dlaczego komputer po każdym włączeniu nie może wyswietlić bitmapy z
ostatniego dnia
lub obrazu startowego w postaci panelu użytkowego, a nie reklamy,
ale musi po kolei coś uruchamiać?
Potem dorobić obsługę naciśnięcia [X;Y] i porównać ją z zakresem dostępnych
w danej chwili działań.
Ja tak bym napisał.
ostatniego dnia
lub obrazu startowego w postaci panelu użytkowego, a nie reklamy,
ale musi po kolei coś uruchamiać?
Potem dorobić obsługę naciśnięcia [X;Y] i porównać ją z zakresem dostępnych
w danej chwili działań.
Ja tak bym napisał.
Fakt, można... chodzi tylko o wygodę
. Pomyśle nad tym, bo to kurcze,
proste jest, mało pamięci potrzebuje i w ogóle
... Fajne ...
Muszę tylko samemu dokładnie określić na czym mi zależy... W Twoim
wydaniu przesunięcie przycisku np. przycisku to kupa roboty - trzeba
przerobić bitmapę na kompie, trzeba ją przekonwertować i dołączyć do
programu, w programie zmienić obszar, na którym ten przycisk obowiązuje.
W przypadku takiej struktury po prostu zmieniam wartości X i Y i
przycisk się sam przesuwa
...
Problem pojawia się po prostu w momencie, w którym chce mieć różne
elementy... na starcie chcę widzieć pulpit z paroma ikonkami i tyle...
potem przechodzić dalej. Czasem mieć klawiaturę numeryczną itp.. czyli
kilka bitmap, które trzeba podmieniać i się w tym nie pogubić
. I tak
muszę stworzyć sobie taką "listę obszarów", gdyż w jednym momencie
danemu (X,Y) przyporządkowany będzie przycisk A, a w innym momencie,
będzie to przycisk B... itd...
Tak więc nie wiem, jak to w sumie wyjdzie
...
Ale pomysł na pewno wart jest przemyślenia. Uwzględniając istniejące
opóźnienie w projekcie, nie wiem, czy się jednak nie skuszę
...
--
Pozdrawiam
Konop
Konop
Guest
Guest
Wed Dec 29, 2010 5:11 pm
W dniu 2010.12.29 15:22, brak pisze:
Quote:
Konop wrote:
Witam
Ma ktoś jakieś doświadczenie w pisaniu *prostego* GUI dla
mikrokontrolerów z wyświetlaczem dotykowym monochromatycznym?
Watpie, zasadniczo to widze dwie drogi :
1. Jak w poscie ponizej - statyczny obrazek w postaci mapy bitowej oraz
napisane z palca psedo-widgety typu np. 3 cyfry w stalym miejscu ( nie ma
mowy o zadnych oknach a tym bardziej historiach typu mysz, przesuwanie
okien czy zdarzenia).
Witam
Ma ktoś jakieś doświadczenie w pisaniu *prostego* GUI dla
mikrokontrolerów z wyświetlaczem dotykowym monochromatycznym?
Watpie, zasadniczo to widze dwie drogi :
1. Jak w poscie ponizej - statyczny obrazek w postaci mapy bitowej oraz
napisane z palca psedo-widgety typu np. 3 cyfry w stalym miejscu ( nie ma
mowy o zadnych oknach a tym bardziej historiach typu mysz, przesuwanie
okien czy zdarzenia).
Pisząc o "oknach" miałem na myśli coś na czymś - to się nie musi
przesuwać ani nic, ale NA PEWNO będę potrzebował kilka różnych
"ekranów"... więc w sumie mała różnica , czy nowy ekran zajmie cały
wyświetlacz, czy będzie nałożony na poprzedni i obramowany (okno
).
Quote:
2. Uzycie istniejacego mikro-GUI - patrz ponizej.
Po lekturze powyzszych wymagan moge stwierdzic iz to "proste" GUI w
implemntacji bedzie calkiem rozbudowanym projektem.
Po lekturze powyzszych wymagan moge stwierdzic iz to "proste" GUI w
implemntacji bedzie calkiem rozbudowanym projektem.
No właśnie, wymagania są małe - proste GUI. To, co napisałem później, to
był efekt mojej analizy ;D...
Quote:
Zasadniczo w takej systuacji polecam wykorzystanie istniejacego tworu lub
chociaz spojrzenie pt. "Jak to robia inni" aby uniknac wywazania otwartych
drzwi.
Jakis czas temu poszukiwalem jakiegos embedded GUI i z projektow open source
jak na razie znalazlem tylko Nano-X -> http://www.microwindows.org/ ale
obawiam sie iz port dla FreeRTOS'a bedzie wyzwaniem - jest on oparty o
architekture klient-serwer co powoduje iz komunikacja odbywa sie przez
sockety BSD na localhostcie
Z komercyjnych ciekawie wyglada C/PEG -
http://swellsoftware.com/products/cpeg.php aczkolwiek tez ne ma portu dla
FreeRTOS'a.
Polecam tez spojrzec na GUI systemiku Contiki -> http://www.sics.se/contiki/
oraz biblioteke graficzna PW dla wyswietlaczy monochromatycznych -
http://sourceforge.net/projects/pwlib/ (jest on blizsza "podejsciu
mikrokontrolerowemu" niz Nano-X).
chociaz spojrzenie pt. "Jak to robia inni" aby uniknac wywazania otwartych
drzwi.
Jakis czas temu poszukiwalem jakiegos embedded GUI i z projektow open source
jak na razie znalazlem tylko Nano-X -> http://www.microwindows.org/ ale
obawiam sie iz port dla FreeRTOS'a bedzie wyzwaniem - jest on oparty o
architekture klient-serwer co powoduje iz komunikacja odbywa sie przez
sockety BSD na localhostcie
Z komercyjnych ciekawie wyglada C/PEG -
http://swellsoftware.com/products/cpeg.php aczkolwiek tez ne ma portu dla
FreeRTOS'a.
Polecam tez spojrzec na GUI systemiku Contiki -> http://www.sics.se/contiki/
oraz biblioteke graficzna PW dla wyswietlaczy monochromatycznych -
http://sourceforge.net/projects/pwlib/ (jest on blizsza "podejsciu
mikrokontrolerowemu" niz Nano-X).
Właściwie o tym FreeRTOSie nie potrzebnie pisałem, bo to taki system,
choćby żaden. Procek to ARM7, obecnie jadę na płytce testowej z LPC2378,
docelowo zastosuję taki, lub jego słabszy "odpowiednik" (mniej pamięci,
bajerów - zależnie od tego ile mi projekt zajmie). Generalnie nie ma tam
systemu a'la linux czy coś
... No ale będę się przyglądał Twoim linkom
...
--
Pozdrawiam
Konop
WoW
Guest
Guest
Wed Dec 29, 2010 6:04 pm
Konop wrote:
Quote:
W dniu 2010.12.29 15:22, brak pisze:
Konop wrote:
Witam
Ma ktoś jakieś doświadczenie w pisaniu *prostego* GUI dla
mikrokontrolerów z wyświetlaczem dotykowym monochromatycznym?
Watpie, zasadniczo to widze dwie drogi :
1. Jak w poscie ponizej - statyczny obrazek w postaci mapy bitowej oraz
napisane z palca psedo-widgety typu np. 3 cyfry w stalym miejscu ( nie ma
mowy o zadnych oknach a tym bardziej historiach typu mysz, przesuwanie
okien czy zdarzenia).
Pisząc o "oknach" miałem na myśli coś na czymś - to się nie musi
przesuwać ani nic, ale NA PEWNO będę potrzebował kilka różnych
"ekranów"... więc w sumie mała różnica , czy nowy ekran zajmie cały
wyświetlacz, czy będzie nałożony na poprzedni i obramowany (okno).
2. Uzycie istniejacego mikro-GUI - patrz ponizej.
Po lekturze powyzszych wymagan moge stwierdzic iz to "proste" GUI w
implemntacji bedzie calkiem rozbudowanym projektem.
No właśnie, wymagania są małe - proste GUI. To, co napisałem później, to
był efekt mojej analizy ;D...
Zasadniczo w takej systuacji polecam wykorzystanie istniejacego tworu lub
chociaz spojrzenie pt. "Jak to robia inni" aby uniknac wywazania
otwartych drzwi.
Jakis czas temu poszukiwalem jakiegos embedded GUI i z projektow open
source
jak na razie znalazlem tylko Nano-X -> http://www.microwindows.org/ ale
obawiam sie iz port dla FreeRTOS'a bedzie wyzwaniem - jest on oparty o
architekture klient-serwer co powoduje iz komunikacja odbywa sie przez
sockety BSD na localhostcie
Z komercyjnych ciekawie wyglada C/PEG -
http://swellsoftware.com/products/cpeg.php aczkolwiek tez ne ma portu dla
FreeRTOS'a.
Polecam tez spojrzec na GUI systemiku Contiki -
http://www.sics.se/contiki/ oraz biblioteke graficzna PW dla wyswietlaczy
monochromatycznych -> http://sourceforge.net/projects/pwlib/ (jest on
blizsza "podejsciu mikrokontrolerowemu" niz Nano-X).
Właściwie o tym FreeRTOSie nie potrzebnie pisałem, bo to taki system,
choćby żaden. Procek to ARM7, obecnie jadę na płytce testowej z LPC2378,
docelowo zastosuję taki, lub jego słabszy "odpowiednik" (mniej pamięci,
bajerów - zależnie od tego ile mi projekt zajmie). Generalnie nie ma tam
systemu a'la linux czy coś... No ale będę się przyglądał Twoim linkom
...
Konop wrote:
Witam
Ma ktoś jakieś doświadczenie w pisaniu *prostego* GUI dla
mikrokontrolerów z wyświetlaczem dotykowym monochromatycznym?
Watpie, zasadniczo to widze dwie drogi :
1. Jak w poscie ponizej - statyczny obrazek w postaci mapy bitowej oraz
napisane z palca psedo-widgety typu np. 3 cyfry w stalym miejscu ( nie ma
mowy o zadnych oknach a tym bardziej historiach typu mysz, przesuwanie
okien czy zdarzenia).
Pisząc o "oknach" miałem na myśli coś na czymś - to się nie musi
przesuwać ani nic, ale NA PEWNO będę potrzebował kilka różnych
"ekranów"... więc w sumie mała różnica , czy nowy ekran zajmie cały
wyświetlacz, czy będzie nałożony na poprzedni i obramowany (okno
).
2. Uzycie istniejacego mikro-GUI - patrz ponizej.
Po lekturze powyzszych wymagan moge stwierdzic iz to "proste" GUI w
implemntacji bedzie calkiem rozbudowanym projektem.
No właśnie, wymagania są małe - proste GUI. To, co napisałem później, to
był efekt mojej analizy ;D...
Zasadniczo w takej systuacji polecam wykorzystanie istniejacego tworu lub
chociaz spojrzenie pt. "Jak to robia inni" aby uniknac wywazania
otwartych drzwi.
Jakis czas temu poszukiwalem jakiegos embedded GUI i z projektow open
source
jak na razie znalazlem tylko Nano-X -> http://www.microwindows.org/ ale
obawiam sie iz port dla FreeRTOS'a bedzie wyzwaniem - jest on oparty o
architekture klient-serwer co powoduje iz komunikacja odbywa sie przez
sockety BSD na localhostcie
Z komercyjnych ciekawie wyglada C/PEG -
http://swellsoftware.com/products/cpeg.php aczkolwiek tez ne ma portu dla
FreeRTOS'a.
Polecam tez spojrzec na GUI systemiku Contiki -
http://www.sics.se/contiki/ oraz biblioteke graficzna PW dla wyswietlaczy
monochromatycznych -> http://sourceforge.net/projects/pwlib/ (jest on
blizsza "podejsciu mikrokontrolerowemu" niz Nano-X).
Właściwie o tym FreeRTOSie nie potrzebnie pisałem, bo to taki system,
choćby żaden. Procek to ARM7, obecnie jadę na płytce testowej z LPC2378,
docelowo zastosuję taki, lub jego słabszy "odpowiednik" (mniej pamięci,
bajerów - zależnie od tego ile mi projekt zajmie). Generalnie nie ma tam
systemu a'la linux czy coś
... No ale będę się przyglądał Twoim linkom
...
arm7 to potwor w porownaniu z contiki
--
+++
Adam Dybkowski
Guest
Guest
Thu Dec 30, 2010 1:38 am
W dniu 2010-12-29 13:32 Konop napisał(a):
Quote:
Będę wdzięczny za wszelkie uwagi do mojego pomysłu .
.
Przyjrzyj się bibliotece Skia:
http://code.google.com/p/skia/
Na procku ARM7 powinna śmigać aż miło. Skia robi rysowanie 2D
podstawowych obiektów, dopiszesz sobie do tego jeszcze tylko obsługę
eventów (klikania) i będzie OK.
BTW: Skia leży na samym dnie Androida, poniżej jest już tylko driver LCD.
--
Adam Dybkowski
http://dybkowski.net/
Uwaga: przed wysłaniem do mnie maila usuń cyfry z adresu.
WoW
Guest
Guest
Thu Dec 30, 2010 11:32 am
Adam Dybkowski wrote:
Quote:
W dniu 2010-12-29 13:32 Konop napisał(a):
Będę wdzięczny za wszelkie uwagi do mojego pomysłu.
Przyjrzyj się bibliotece Skia:
http://code.google.com/p/skia/
Na procku ARM7 powinna śmigać aż miło. Skia robi rysowanie 2D
podstawowych obiektów, dopiszesz sobie do tego jeszcze tylko obsługę
eventów (klikania) i będzie OK.
BTW: Skia leży na samym dnie Androida, poniżej jest już tylko driver LCD.
Będę wdzięczny za wszelkie uwagi do mojego pomysłu
.
Przyjrzyj się bibliotece Skia:
http://code.google.com/p/skia/
Na procku ARM7 powinna śmigać aż miło. Skia robi rysowanie 2D
podstawowych obiektów, dopiszesz sobie do tego jeszcze tylko obsługę
eventów (klikania) i będzie OK.
BTW: Skia leży na samym dnie Androida, poniżej jest już tylko driver LCD.
A znasz moze jakas biblioteke do grafiki 2D. Krzywe beziera, odleglosc od
krzywej, koła. grubosc linii zmienna, odleglosc na krzywej.
--
+++
Adam Dybkowski
Guest
Guest
Thu Dec 30, 2010 11:07 pm
W dniu 2010-12-30 11:32 WoW napisał(a):
Quote:
Przyjrzyj się bibliotece Skia:
http://code.google.com/p/skia/
Na procku ARM7 powinna śmigać aż miło. Skia robi rysowanie 2D
A znasz moze jakas biblioteke do grafiki 2D. Krzywe beziera, odleglosc od
krzywej, koła. grubosc linii zmienna, odleglosc na krzywej.
http://code.google.com/p/skia/
Na procku ARM7 powinna śmigać aż miło. Skia robi rysowanie 2D
A znasz moze jakas biblioteke do grafiki 2D. Krzywe beziera, odleglosc od
krzywej, koła. grubosc linii zmienna, odleglosc na krzywej.
Przejrzyj kod źródłowy np. programu Inkscape (to jest coś a'la wektorowy
Corel Draw czy Adobe Illustrator). Rysowanie krzywych powinno gdzieś tam
siedzieć, niewykluczone że w większej bibliotece "do wszystkiego". I jak
najbardziej tylko 2D.
--
Adam Dybkowski
http://dybkowski.net/
Uwaga: przed wysłaniem do mnie maila usuń cyfry z adresu.
Jarosław Sokołowski
Guest
Guest
Fri Dec 31, 2010 12:36 am
Pan Adam Dybkowski napisał:
Quote:
A znasz moze jakas biblioteke do grafiki 2D. Krzywe beziera, odleglosc
od krzywej, koła. grubosc linii zmienna, odleglosc na krzywej.
Przejrzyj kod źródłowy np. programu Inkscape (to jest coś a'la wektorowy
Corel Draw czy Adobe Illustrator). Rysowanie krzywych powinno gdzieś tam
siedzieć, niewykluczone że w większej bibliotece "do wszystkiego". I jak
najbardziej tylko 2D.
od krzywej, koła. grubosc linii zmienna, odleglosc na krzywej.
Przejrzyj kod źródłowy np. programu Inkscape (to jest coś a'la wektorowy
Corel Draw czy Adobe Illustrator). Rysowanie krzywych powinno gdzieś tam
siedzieć, niewykluczone że w większej bibliotece "do wszystkiego". I jak
najbardziej tylko 2D.
I jeszcze do źródeł wszystkich źródeł, czyli do METAFONTa. Zwłaszcza jak
ktoś chce wiedzieć o co Knuthowi chodziło z tymi bezierami i bernsteinami.
Oczywiście nie do źródeł w sensie pliku mf.web -- to trzeba przepuuścić
przez program weave aby otrzymać algorytm z komentarzami i opisami
w wygodnej formie podręcznika. Do tego można jeszcze się dowiedzieć jak
zrobić dobrą rasteryzację tych wektorów.
--
Jarek
SĹawomir Szczyrba
Guest
Guest
Fri Dec 31, 2010 8:40 am
Klik-klik-klik... To WoW donosi :
Quote:
A znasz moze jakas biblioteke do grafiki 2D. Krzywe beziera, odleglosc od
krzywej, koła. grubosc linii zmienna, odleglosc na krzywej.
Moze libart?
<http://www.levien.com/libart/>
Sławek
--
________
_/ __/ __/ It is forbidden to forbid.
\__ \__ \_______________________________________________________________
/___/___/ Sławomir Szczyrba steev/AT/hot\dot\pl
elektroda NewsGroups Forum Index - Elektronika Polska - Optymalna struktura dla prostego GUI na mikrokontrolery z wyświetlaczem dotykowym