Jak se překládají události

class PozarniAlarm {
  public event EventHandler Hori;
}

Při pohledu na kód vygenerovaný překladačem pro událost je vidět, že pro událost je překladačem vygenerovaný delegát se stejnou signaturou, jakou má událost a se stejným jménem jako má událost; dále pro ni jsou vygenerovány metody add_Hori(EventHandler) a remove_Hori(EventHandler).

Pokud v kódu pracujeme s událostí pomocí jejího názvu, až na operátory += a -= pracujeme právě s tímto delegátem. Zmíněné operátory se pochopitelně přeloží na volání odpovídající metody add_Hori, nebo remove_Hori.
Události, které by zachycovaly přidání nebo odebrání klienta události neexistují, ale nabízí se otázka, jestli by nebylo možné nějakým způsobem přetížit ony metody pro += a -=. A jak zní odpověď? Ale samozřejmě…

Vlastní add a remove

Podobně jako se u properties zadávají bloky kódu pro přečtení a zápis hodnoty, zadávají se i bloky kódu pro přidání a odebrání handleru, celková struktura je properties velmi podobná.

class PozarniAlarm {
  public event EventHandler Hori {
    add {
      // ... kód pro přidání obsluhy ...
    }
    remove {
      // ... kód pro odebrání obsluhy ...
    }
  }
}

Pokud části add a remove neuvedete, překladač automaticky za vás vygeneruje kód analogický tomuto pro přidávání

Hori = (EventHandler)EventHandler.Combine(Hori, value);

a tomuto pro odebírání

Hori = (EventHandler)EventHandler.Remove(Hori, value);

Hori v těchto blocích kódu samozřejmě vystupuje ve významu delegáta, ve kterém se akumulují všechny delegáty přidané k události pomocí operátoru +=.

Pokud naopak bloky add a remove zadáme, překladač automaticky negeneruje proměnnou akumulující přidané delegáty a je nutné se o ni postarat. A tato proměnná, kterou pro událost vytvoříme ručně bohužel nesmí mít stejné jméno jako událost. Škoda…

Spojení s callback funkcí

V tomto bodě už je jednoduché do procesu vstoupit a ve vhodnou chvíli zaregistrovat svou callback funkci, která událost vyvolává.

class PozarniAlarm {
  public event EventHandler Hori {
    add {
      // zjednodušená syntaxe pro spojování delegátů
      m_HoriListeners += value;
      // pokud se k události přihlásil první čekatel, zaregistruj
      // callback funkci
      if(m_HoriListeners.GetInvocationList().Length == 1)
        RegisterCallback();
    }
    remove {
      // pokud se odhlašuje poslední čekatel, odregistruj
      callback funkci
      if(m_HoriListeners.GetInvocationList().Length == 1)
        UnregisterCallback();
      m_HoriListeners -= value;
    }
  }
  // pro události, kde jsou zadané add a remove se proměnná
  // udržující seznam přidaných delegátů nevygeneruje
  // automaticky, musíme si jí vyrobit sami
  private EventHandler m_HoriListeners;

  private void RegisterCallback() {
    // ... proveď registraci callback funkce vyvolávající
    //     událost Hori ...
  }

  private void UnregisterCallback() {
    // ... zruš registraci callback funkce vyvolávající
    //     událost Hori ...
  }
}

Právě do takové situace jsem se dostal při práci na programu pro seminář k přednášce Implementace neuronových sítí II. Mojim cílem bylo rychle a s vynaložením co nejmenší námahy naprogramovat zobrazení kohonenovské sítě operující v trojrozměrném vstupním prostoru (jednotlivé neurony lze reprezentovat jako body v 3D prostoru).

Požadovaným výsledkem bylo zobrazení několika desítek neuronů a zobrazení spojů mezi sousedními neurony v mřížce. Pro reprezentaci neuronu bohatě postačí “koule” složená z dvacítky polygonů, pro spoje jednoduché čáry. Dokud jsem síť potřeboval zobrazit jen ve dvou rozměrech, bylo možné používat velice komfortní grafické funkce z prostoru System.Drawing. S druhým rozměrem ale jejich možnosti končí a Microsoftem podporované Managed DirectX je dimenzované pro větší projekty vyžadující vyšší výkon a možnost využívat pokročilé funkce moderních grafických karet. Zřejmě i proto v něm chybí možnost jak jednoduchým způsobem kreslit základní grafická primitiva.

OpenGL vrací úder

Při pohledu du Managed DirectX dokumentace jsem se slzou v oku zavzpomínal na krásné časy s glBegin, glEnd a glVertex při programování grafického engine Projektu 5410 a pokusil se spolu s Googlem najít způsob, jak spojit výhodu jednoduchého programování grafiky pomocí OpenGL s výhodou rychlého psaní kódu v C# (a samotřejmě s hotovými třídami pro kohonenovské sítě) a po chvíli hledání se zjevilo řešení téměř dokonalé – CsGL.

Podle seznamu novinek na webu knihovna už skoro třetím rokem není udržovaná, to ale nic nemění na její použitelnosti a užitečnosti. K dispozici programátorům dává kompletní rozhraní OpenGL 1.4 s vybranými rozšířeními (kompletní seznam podporovaných je na webu). Součástí jsou i funkce z GLU a vybrané funkce z GLUT.

Objektově orientováno

Protože OpenGL samo není objektové rozhraní, museli se autoři CsGL vyrovnat s přenosem na platformu, která naopak je na objekové orientovanosti založena. Samotné funkce glXXX zůstávají statické a jejich efekty se vážou vždy k aktuálnímu grafickému kontextu. I přes neobjektovost velké části rozhraní OpenGL se ale autorům podařilo několik samostatných tříd izolovat – především se jedná o grafický kontext reprezentující aktuální výstupní okno a o framework zjednodušující vytváření aplikací, který nahrazuje funkce pro práci s okenním systémem z GLUT.

Začlenění frameworku zajišťujícího vytvoření okna a vlastní smyčky zpráv do existující aplikace je skoro nemožné, proto jsem při práci ocenil spíše ovládací prvek OpenGLControl, který ve standardní třídě Control přidává možnost vykreslovat obsah ovládacího prvku pomocí funkcí CsGL místo obvyklého System.Drawing. Vytvoření komponenty zobrazující požadovanou trojrozměrnou neuronovou síť pak už bylo dílem okamžiku.

Další vývoj

Jak už jsem psal na začátku příspěvku, knihovna od poloviny roku 2003 není dále vyvýjena a udržována, to ale neznamená, že by se jednalo o slepou vývojovou cestu. Další vývoj totiž probíhá v rámci projeku Mono, kde je pod názvem Tao vytvářena komplexní knihovna pro vývoj her a multimediálních aplikací – kromě OpenGL ve verzi 1.5 jsou podporovány i další knihovny a API jako je OpenAL pro práci se zvukem, ODE pro fyziku pevných těles nebo vše sdružující platformově nezávislé SDL.

Narozdíl od CsGL se knihovna Tao snaží o maximální nezávislost na platformě, která může být výhodou, ale na druhou stranu z pochopitelných důvodů došlo k znatelnému nárůstu velikosti dll knihoven a potenciálnímu snížení výkonu. Proto pokud cílem je jednoduchá aplikace pro platformu Windows, která nepoužívá nejnovější funkce grafických akcelerátorů, je menší a specifičtěji zaměřené CsGL stále dobrou volbou.