Tworzenie niskopoziomowego GUI - Algorytmy

Wtedy wykrywanie polegałoby na pobraniu ID z określonego (x, y) i wykonanie akcji, niestety kosztem pamięci RAM. Jednakże wolałem się dowiedzieć jakie mogą być jeszcze sposoby na to. Tak masz racje, elementów może nie być dużo i szybkość nie jest pierwszoplanowa. Aczkolwiek zawsze najpierw staram się wyznaczyć najoptymalniejsze metody, nawyk z programowania mikrokontrolerów.

Ale o ograniczeniach pamięciowych mikrokontrolerów już się zapomniało? ;) Jest to jakieś rozwiązanie, ale wymaga dużo pamięci i ma istotne problemy. Co jeśli chcesz mieć możliwość zmiany rozmiarów okna? Co jeśli kontrolki mogą zmieniać położenie? Co jeśli mogą się na siebie nakładać? W praktyce zwykłe przejście po wszystkich kontrolkach jest preferowanym rozwiązaniem, bo kontrolek nigdy nie ma dużo, a operacja jest wykonywana raz na jedno zdarzenie myszki. Możesz wprowadzać dodatkowe optymalizacje tego sposobu, przykładowo

• Wyznaczanie prostokąta, który myszka musi opuścić, zanim algorytm będzie wykonany ponownie. Jak najedziesz na kontrolkę, to ruch w jej obrębie nic nie zmienia.
• Zapisanie prostokątów wszystkich kontrolek w tablicy, dla lepszego cache spatial locality. Jest to jednak coś do aktualizowania przy zmianach w kontrolkach.

I tak kontrolek musiało by być niemoralnie dużo, żeby wybór algorytmu zauważalnie poprawił wydajność na komputerze sprzed 10 lat.

@pekfor haha no widzisz, w PC już nie ma KB pamięci RAM więc można szaleć :D Masz rację, myślę że wtedy najlepsza będzie prosta operacja przelecenia po wszystkich kontrolkach na zasadzie Punkt-Prostokąt AABB trigger. Aczkolwiek w tej metodzie będę musiał wymyślić jeszcze jak zadziałać z kontrolką w kontrolce.

Przy okazji odpowiem Ci na twoje pytania.

"Co jeśli chcesz mieć możliwość zmiany rozmiarów okna?" Jeśli nie zmieniono znów rozmiaru okna przez określony czas, na nowo wygenerować strukturę w pamięci. Można zoptymalizować do 1-Bajtu, wtedy jest ograniczenie do 255 kontrolek + np wciśnięcie tła.

"Co jeśli kontrolki mogą zmieniać położenie?" Tego akurat nie zakładałem, bo myślałem bardziej o statycznym GUI przy stałych rozmiarach okna. Aczkolwiek wtedy ta metoda wychodzi bardzo nieoptymalnie. (Zwykły scrollbar)

"Co jeśli mogą się na siebie nakładać?" Tutaj nie widzę problemu, skoro każdy pixel ma odrębne ID. Można po prostu wbudować prostokąt (np. button) w jakąś kontrolkę i tyle. Przy odczycie po prostu będzie inne ID.

Aczkolwiek w tej metodzie będę musiał wymyślić jeszcze jak zadziałać z kontrolką w kontrolce.

Kontrolka w kontrolce to jedna kontrolka - ta zewnętrzna. Możesz wziąć przykład z WinAPI, gdzie wszystko (okno, kontrolka) jest oknem, które może zawierać kontrolki.