Amugy nem vagyok rola meggyozodve (ellenorizni kene!), hogy SymbOS nem kenyszeriti ki a 8 pixeles hatarokat pl ablak poziciora. Ez csak egy tipp, de epp gondolkodtam, hogy a fenebe lehet megoldani, hogy egy felig 4db ablakkal takart masik ablakban aktivan van vmi, es csak az frissuljon, ami nincs kitakarva persze. Arra jutottam, hogy a legegyszerubb megoldas, ha pl 8*8-as (vagy mas, mind1, de a 8 logikusnak tunik legalabb vizszintesen) egysegenkent van a memoriaban egy "terkep" ami azt mutatja, hogy az adott "pixel blokk" melyik ID-el rendelkezo ablakhoz tartozik. Igy a rajzolo rutinoknak konny dolga van viszonylag. Persze elvileg akar pixelnekent is lehetne terkep, csak az durvan nagy lenne, nagyobb mint a teljes grafikus videoRAM merete 4 colour felobontasban
Marmint, ha 1 byte van a window ID-re a SymbOS-en belul. Mas megoldast nem tudok elkepzelni hirtelen viszont, hogy hatekonyan hogy van lekezelve a felig takart ablak esete. Foleg, ha tenyleg sok ablak itt-ott takarja, akkor azert nem piskota kitalalni, hol latszik es hol nem eppen ... Szoval ezert tippelek a "terkep" megoldasra. Persze lehet, hogy tevedek. Ha pedig uj ablak jelenik meg, arrebb viszel egyet, bezart egyet stb, akkor a SymbOS-nek persze ujra kell generalnia az adott "terkep" vonatkozo reszet.
Ha tenyleg igy van, es "blokkosan", akkor lehet amugy is adott mar eleve, hogy ablak nem lehet "akarhol" hanem pl 8 pixelkent vagy tudomisen, ami hasznos lehet a fentebb vazolt technikakhoz. Vagy az is lehet, hogy ez a "blokossag" merteke allithato a SymbOS-ben (nem is usernek, hanem forraskod szinten marmint) es osszefuggesbe hozhato az attribute mode kivanalmaival.
Meg kene kerdezni a szerzot, hogy mukodi ez valojaban