| Yazar | D. Huff | | Kurum | CWRU (Case) | | Tarih | 15 Aralık 1971 | | Durum | Network Working Group Yorum Talebi | | RFC Numarası | 285 |
NIC koleksiyonunun hacmi göz önüne alındığında ARPANET üzerindeki grafikler hakkında çok az şey yazılmıştır. Günümüzde bu koleksiyon yaklaşık 8000 giriş içermektedir ve bunların yalnızca yaklaşık 20 tanesi grafik konusundadır. Bunun nedeni muhtemelen L. G. Roberts tarafından A FORWARD LOOK (NIC 7542) içinde verilen ve veri tabanı paylaşımı ya da yazılım paylaşımının birkaç yıl daha önemli konular olmayacağına dair açıklamaya benzerdir: NET, ilgilenen kişilerin bunun uygulanabilir olup olmadığını anlayacak ve inovatif biçimde düşünecek kadar yeterli olguyu biriktirmesine olanak verecek kadar uzun süredir çalışmamaktadır.
Bu nedenle bu makalenin amacı, NET üzerindeki grafiklerin mevcut durumunu yeni başlayanlar için bir araya getirmek ve şimdiye kadar kat edilen mesafeye biraz daha katkı sağlamaya çalışmaktır. Önce genel bir bakış sunacağım, ardından geçmiş çalışmaları kısaca açıklayacağım ve son olarak kendi düşüncelerimden bazılarını ekleyeceğim.
NET çok sayıda veri işlemcisi barındırdığından ve bunların herhangi biri ya da hepsi aynı anda kullanılabildiğinden, ana işlemci ve ona göre daha az yetenekli bir makinenin —ya da bazen hiç bulunmayan— bir görüntü işlemcisi olarak görev yaptığı özel kurulumlarda yaygın olarak bulunan yapılandırmalarla sınırlı değiliz. Hatta NET kullanılırken, ana işi çalıştıran makineden daha güçlü bir makinenin görüntü işlemcisi olarak kullanıldığı durumlar bile ortaya çıkabilir. NET üzerindeki grafikler, bugün bildiğimiz biçimde olmak zorunda değildir.
Elbette standart bir grafik dili ve onun işlemcisini tasarlarken dikkate alınması gereken çok daha geniş ve çeşitlenmiş bir grafik donanımı karışımı vardır. Bir programdan rastgele bir görüntü aygıtını sürmek istiyorsak, böyle bir çıktı dilinin oldukça genel olması gerekir; ancak hedef görüntü aygıtı için gerçek görüntü listesini oluşturan işlemcinin genel olması gerekmez ve gerçekte olmayacaktır. Bunun yerine görevi yalnızca iyi tanımlanmış genel bir dili, belirli bir grafik terminalinin gereksinimlerini karşılayacak biçimde çevirmektir.
Son zamanlarda tartışılan ve oldukça kaygı uyandıran bir konu olan dikkat işleme (attention handling) ise tamamen farklı bir problem sunar. Bu kez NET, basit bir nedenle faydadan çok zarar verebilir: artık ana iş sürecinin oluşturduğu başlangıç görüntü listesinden, ışık kalemi gibi etkileşimli aygıtların gerçekten başvurduğu son görüntü listesine ulaşmak için tek bir eşleme yerine birden fazla eşleme tanımlı olabilir (bazı durumlarda ise hiç olmayabilir). Bu, ele alınması gereken ve birçok farklı yerde çok farklı yöntemlerle çözülmüş bir problemdir. Nihai kavram kadar sorun çıkarma olasılığı vardır.
Yerel işleme, görüntü terminali "akıllı" olduğunda ya da ekranı yenilemek dışında çok az işi olan orta veya büyük ölçekli kendi işlemcisine sahip olduğunda birçok durumda oldukça basit biçimde gerçekleştirilebilir. Böyle bir işleme, ana iş sürecinin gerçekleştirmesini gerektirmeyen, resme yapılacak basit ekleme veya silmeler olabilir. Yerel işlemcinin yapması gereken tek şey, görüntü listesinde hangi değişikliklerin yapıldığını ana sürece bildirerek ana kopyanın güncellenmesini sağlamaktır. Yetki ve görevlerin dağıtımı ise son problemi oluşturur. Alt sınır, yerel işlemcinin resmi ekranda tutmaktan başka hiçbir şey yapamadığı durumdur; üst sınır ise yerel işlemcinin ana işlemciden daha güçlü olduğu ve tüm dikkat işlemlerini kendisinin ele aldığı durumdur. Bu noktada, görüntü listesinin hangi kopyasının ana kopya olduğu, tüm kopyaların aynı bilgiyi içerdiğini sağlamaktan kimin sorumlu olduğu ve görüntü listeleri arasında ne tür eşlemelerin gerektiği gibi sorular cevaplanması gereken temel sorular haline gelir.
Ağ için Standart Grafik önerileri, yalnızca ekranı temizleme, bir metin dizisini görüntüleme, ışını hareket ettirme ya da genelleştirilmiş ekranı temsil eden sanal bir dikdörtgen içinde bir çizgi veya nokta çizme, daha önce tanımlanmış bir alt yordamı çalıştırma ve bir alt yordamın içeriğini komut akışında gelenlerle değiştirme gibi komutları içeren basit ve yorumlanabilir bir dil fikriyle başlamıştır. Ekran alanı içindeki hareketler mutlak uzunluklar yerine ekran boyutlarının kesirleri cinsinden tanımlanmıştır. Bu öneriye verilen yanıtlarda, bir grafik standardının bu kadar kısıtlayıcı olamayacağı ve geniş kabul görmeyeceği ileri sürülmüştür. Öneri, gelişmiş resim işlemlerini ele almak için yeterince ifade gücüne sahip değildi. Bir standardın mevcut ve öngörülebilir gelecekteki tüm grafik donanımlarından yararlanabilmesi gerektiği kabul edilmiştir. Veri yapısı hem mantıksal hem de görsel yapıyı temsil etmeli, alt resimlerin tanımlanmasına ve işlenmesine izin vermeli ve ekranın mantıksal birimlere bölünebilmesini sağlamalıdır. Önerilen standart artık düşük seviyeli bir dil yerine genel ve yüksek seviyeli bir dil haline gelmiştir. Tüm sitelerin bu grafik dilini yorumlayabilecek kapasitede olması gerekmediği, ancak NET’in varlığı sayesinde diğer makinelerden birinin yorumlayıcıyı çalıştırabileceği belirtilmiştir; bu durum veri yeniden yapılandırma hizmetine eşdeğerdir. Yoğunluk, yanıp sönme, kesik çizgi, renk veya stereo gibi çizim modlarının da bir mod ayarlama komutu aracılığıyla ifade edilebilmesi gerekir. Herkesin metin gösterimi için farklı yöntemleri olduğundan ve bunların çoğu birbirinden farklı olduğundan, karakter dizilerinin kanonik bir tanımı yapılmalıdır. Osanna, J., Sahzer, J., Remote Terminal Character Stream Processing of Multics, Proceedings SJCC, 1970, s. 671’de açıklanan Multics kuralının kullanılması önerilmektedir.
Grafik bilgilerini yalnızca görüntülemekten öte, resimle doğrudan etkileşim kurmak isteniyorsa, protokol geri bildirim için bir standart içermelidir; buna dikkat işleme (attention handling) adı verilmektedir. Ancak dikkat sinyalleri her zaman doğrudan resme gönderme yapmaz; örneğin klavye girişi durumunda, bu veri NET üzerindeki diğer standart mesajlar gibi ele alınabilir. Bazı grafik işlemcileri dikkat işlemlerini yerel olarak da gerçekleştirebilir ve yalnızca nihai sonucu ana sürece rapor etmeleri yeterli olabilir. Burada sorun, hangi veri yapısının en güncel olduğu, hangisinin ana kopya olarak kabul edildiği ve süreçlerin nasıl eşzamanlı tutulacağıdır. Ayrıca şu gözlem de yapılmaktadır: grafik uygulama programı yani ana süreç, ağ standardı bir dilde çalışan iki grafik aygıtı işleme yordamı ile iletişim kurduğu sürece, sistem yapılandırması keyfi olabilir ve herhangi bir terminal herhangi bir ana sürece bağlanabilir. Aynı durum dikkat işlemleri için de geçerlidir; belirli bir aygıt tarafından üretilen dikkat sinyalinin iletilmesine yönelik standartlar geliştirildiğinde, herhangi bir grafik terminali herhangi bir ana süreç tarafından anlaşılabilir hale gelecektir. Girdi aygıtlarının bir özeti verilmiş, tipik çıktılarla birlikte her dikkat mesajının dikkat oluşturan aygıtı, sağlanan veri türünü ve verinin kendisini tanımlaması önerilmiştir.
Önerilen grafik protokolü görüntü türleri bakımından çok daha zengin hale gelmiştir. Aşağıdaki liste temel olarak önerilmiştir:
- noktalar
- çizgiler
- vektörler
- karakter dizileri
- görüntü alanı (viewport) ve pencere (window)
- örneklerin dönüşümleri
- donanıma bağımlı bayt akışları
- dikkat komutları
Gri tonlu aygıtlar için özel değerlendirmelerin gerekli olduğu da belirtilmiş ve dört alternatif görüntü modu tartışılmıştır (NIC 7128).
Donanım paylaşımına bir örnek NIC 7130’da açıklanmaktadır. Bu, NET üzerindeki herhangi bir kullanıcının LDS-1 için bir programı varsa M.I.T.’deki LDS-1 işlemcisini kullanabilmesini sağlayan bir protokoldür. Graphics Loader adı verilen bu mekanizma, M.I.T.’deki PDP-10’a gönderilen programların çalıştırılmasını ve program yürütüldüğünde oluşan verilerin geri gönderilmesini sağlar. Resim bir görüntü aygıtında çizilmez; ancak LDS-1 işlemcisine ürettiği koordinatlarla ne yapılacağı bildirilebildiğinden, Graphics Loader işlemciyi hesaplanan görüntü koordinatlarını ana belleğe geri yazacak şekilde ayarlar. Bu koordinatlar daha sonra görüntülenmek üzere veya hata ayıklama amacıyla kaynak siteye geri gönderilebilir.
NIC 7137’de daha önce tartışılan bu noktaların birçoğu yeniden ele alınmıştır; ancak bu kez grafik terminalinin minimum özel ayrıcalıklara sahip sıradan bir terminal olması gerektiği varsayımıyla değerlendirilmiştir. Ayrıca özellikle görüntü yapısı, dikkat işleme, koordinat sistemleri ve depolama tüplü ekranlarla yenilemeli ekranların gereksinimleri arasındaki farklara vurgu yapılarak grafik protokolü tasarımına ilişkin öneriler sunulmuştur.
Tablet giriş verilerinin işlenmesine yönelik belirli bir çözüm sunulmuştur (NIC 7151). Bununla birlikte grafik protokolünün, etkileşimli olmayan grafiklerin, protokolün etkileşimli yönlerinin getirdiği gereksinimlerle karmaşık hale gelmemesi için tasarlanması gerektiği ifade edilmiştir. Grafik sürecine giriş olarak gönderilebilecek çeşitli tablet veri türleri olduğu belirtilmiştir. Dört veri türü tanımlanmaktadır: tek atımlı (single-shot), ham asenkron, ham senkron ve ön işlenmiş veri. Ön işlenmiş veri, veriyi daha düzenli ve işlenebilir hale getirmek için çeşitli tekniklerle yumuşatılabilir, filtrelenebilir veya seyreltilmiş hale getirilebilir. Verinin yorumlanmasına yardımcı olmak için her nokta için hızlar da hesaplanabilir.
NETCRT’nin (NIC 7172) açıklaması, yerel işleme ile —ya da onun yokluğuyla— ilk karşılaşmayı temsil eder. NETCRT, merkezi bir işlemci ile bir karakter ekranı arasındaki bir protokoldür. Karakter ekranı tamamen merkezi işlemciye bağlıdır ve yerel işleme gerçekleştiremez; ancak işlemciyi kesintiye uğratabilir ve böylece kullanıcının yazmayı bitirdiğini veya yazmaya başlamak istediğini bildirir. NETCRT, terminalin durumunu kontrol ederek iyi bir insan-makine etkileşimi sürdürmeye çalışır.
Bu makalede özetlediğim çeşitli öneriler hakkında yorum yapmaktan özellikle kaçındım; çünkü bunun bu makaleyle ulaşmak istediğim amaçla uyumlu olmayacağını düşünüyorum. Tasarlamaya çalıştığımız grafik sistemi için genel bir modeli ele alma gereksinimi olduğunu düşünüyorum. Önceki öneriler belirli ayrıntı kümeleriyle ilgilenmiş, ancak genel bir modelle ilişkilendirilmemiştir; bu da ayrıntıların uygulanmasına yönelik iyi fikirler ortaya çıkarmış, fakat bütünün nasıl bir araya geleceği yeterince ele alınmamıştır. Bu nedenle grafik sistemimiz için bir model önermek istiyorum. Bu model birçok protokol içerecek ve daha sonra tartışılması gereken birçok alan bırakacaktır; ancak çalışmaların basit çizgiler boyunca ilerleyebileceği bir başlangıç noktası sağlayacak ve daha gelişmiş yeteneklerin ileride eklenmesini de dışlamayacaktır.
Şekil 1 bilgi akışının bir blok diyagramını göstermektedir. PROCESS, NET üzerindeki bir bilgisayarda çalışan bir grafik uygulama programını ifade eder. Bununla ilişkili INPUT ve OUTPUT yordamları, ana PROCESS ile birlikte yüklenen bir alt yordamlar kümesi olarak ya da başka bir yerde çalışan ve birçok kullanıcıya hizmet veren ayrı bileşenler olarak düşünülebilir. Döngünün diğer ucunda ise grafik bilgilerini görüntülemek için kullanılan DISPLAY aygıtına yönelik INPUT ve OUTPUT sürücüleri bulunur. PROCESS’ten DISPLAY’e akan bilgi, resimlerin oluşturulması ve işlenmesi için kullanılan çizim bilgisidir. DISPLAY’ten PROCESS’e akan bilgi ise dikkat bilgisidir. Ana PROCESS ile ilişkili Grafik Veri Tabanı, resim PROCESS tarafından çizilirken veya resim yerel işleme tarafından çizilirken ve dikkat mesajları PROCESS’e resimde neler yapıldığını bildirdiğinde oluşturulan yapıdır. Bu veri tabanı, PROCESS’in çalışmak istediğinden daha fazla bilgi içermek zorunda değildir; hatta resimle etkileşim yapılmayacaksa hiçbir şey içermeyebilir. DISPLAY sürücüleriyle ilişkili Grafik Veri Tabanı ise sürücüler tarafından oluşturulur; böylece OUTPUT sürücüsü DISPLAY’ten gelen dikkat sinyallerini ana PROCESS’e ihtiyaç duymadan işleyebilir ve INPUT sürücüsü gerçek görüntüye göre resmi değiştirirken bu veriyi kullanabilir. Ana PROCESS’e gidip gelen bilgi, yordam parametreleri olarak iletilen veya alınan türdedir. INPUT ve OUTPUT yordamları, sırasıyla, ağ standardı bir grafik protokolüne çeviri yapar veya bu protokolden geri çeviri yapar. Bu protokol NET üzerinden DISPLAY için çalışan INPUT ve OUTPUT sürücülerine gönderilir; bu sürücüler standard mesajı DISPLAY’i sürmek için uygun bayt akışına çevirmek veya DISPLAY’ten gelen dikkat sinyalini ağ standardı bir mesaja dönüştürmekle sorumludur. DISPLAY’in, eğer gerekiyorsa, kendi ekran yenilemesini kendisinin gerçekleştirdiği varsayılır; böylece yenilemeli ve yenilemesiz ekranlar arasındaki görünür fark mümkün olduğunca az olur.
Bu model, basit işler yapanlar için kullanım kolaylığı sağlarken, gelişmiş etkileşimli grafikler geliştirenler için gerekli gücü de sunar. Çalışma zamanı koşulları etkileşimli grafik yapılmayacağını ve ilgili tüm işlemlerin atlanacağını belirtecek şekilde ayarlanarak minimum çaba ve ek yükle kullanılabilir; buna rağmen diğer PROCESS’ler tamamen farklı bir yordam ve kural kümesine geçmek zorunda kalmadan güçlü grafik işlemleri gerçekleştirebilir.
Birbirleriyle güncel tutulması gereken iki ayrı veri tabanı bulunduğundan, bu modelin iki çalışma modu vardır. Daha iyi adlar bulunamadığı için bunlara PROGRAM grafikleri ve LOCAL grafikleri diyelim. İlki, görüntülenen resmin ana PROCESS tarafından oluşturulduğunu ve ekran üzerindeki kullanıcıdan gelen tüm girişlerin özellikle istendiğini ifade eder; dolayısıyla DISPLAY veri tabanı yalnızca ana PROCESS’in eylemi sonucunda güncellenir. İkincisi ise ekrandaki kullanıcının işlev düğmeleri ve çizim araçları aracılığıyla bir resmin oluşturulmasını yönlendirdiğini ifade eder. DISPLAY veri tabanı hemen güncellenir ve ana PROCESS’e değişiklik bildirilir, böylece ana süreç duruma ayak uydurabilir; ancak DISPLAY OUTPUT sürücüsü tarafından istenmedikçe resim üzerinde işlem yapmaz. Bu durum, DISPLAY INPUT/OUTPUT sürücülerinin kendi başlarına gerçekleştirebileceği bir işlev isteğinin sonucu olabilir veya kullanıcının ana PROCESS’ten resim üzerinde standart olmayan bir işlev gerçekleştirmesini istemesinin sonucu olabilir.
Bu tasarımın temel amacı, en kısa yanıt süresinden ziyade grafik yapılandırmalarında mümkün olan en yüksek genelliği sağlamaktır. En uygun tasarım için donanım yapılandırmasının ve önerilen kullanımın daha kesin biçimde tanımlanması gerekir. Bu değişkenlerin hiçbiri bilinemeyeceği için ve aslında genellik sağlama çabamız bu konularda çok yakın tahminler yapmamızı bile engellediği için, sabit bir en uygun kırılma noktası tasarlamaya çalışmak yerine, işledikleri DISPLAY türüne bağlı olarak işlem yükünü kendileri ile ana PROCESS arasında nasıl paylaştıracaklarını bilen akıllı INPUT/OUTPUT sürücüleri sağlamamız gerekir.
Graphics Protocol, INPUT ve OUTPUT rutinleri ile sürücüler arasında iletilen mesajların biçimini belirtmelidir. Bu mesajlar, daha önce belirtildiği gibi, yönlerine ve içeriklerine göre ikiye ayrılabilir; yani çizim mesajları ve dikkat mesajları. Grafikler ile metnin sıklıkla birlikte kullanılmasının istendiği durumlar olduğundan, tüm grafik mesajları için ayırt edici bir mesaj başlığı bulunmalıdır. Bunun ardından mesaj gövdesinde bulunan bilginin türünü belirten bir bayt, gövdedeki bayt sayısını gösteren bir sayaç ve son olarak da mesaj gövdesinin kendisi gelmelidir. Gerekli mesaj türlerinin neredeyse tamamı önceki RFC'lerde belirtilmiştir ve burada tekrar listelemeyeceğim; yalnızca, dikkat mesajlarının artık sürücülerin gerçekleştiremediği işlemler için yapılan işlem taleplerini de içerdiğini belirtmek gerekir.
Özetlemek gerekirse, hem gelişmiş etkileşimli grafiklerin hem de düşük çaba gerektiren etkileşimsiz grafiklerin tasarımını mümkün kılmak için basit bir modelin yeterli olduğuna inanıyorum. Bunun temel nedeni, asıl ilgimizin en düşük yanıt süresi değil, mümkün olan en geniş yapılandırma karışımlarını elde etmektir. INPUT/OUTPUT rutinleri ve sürücüler geliştirilirken yazılım paylaşımı ve veri yeniden yapılandırma hizmetlerinden yararlanma fırsatları vardır. Yapılması gereken çok sayıda ayrıntılı çalışma hâlâ bulunmaktadır; ancak önerilen fikirlerin değerlendirilmesi için bir çerçeve sağlayan temel bir model görünür durumdayken, çalışmaların daha sorunsuz ilerleyebilmesi gerekir.
RFC 285 — NIC 8271
+---------+ +--------+
! INPUT ! ! OUTPUT !
+--! routine !! ! DISPLAY !
! ! Base ! ! Base ! ! ! !
+---------+---------+ +---------+ ! +---------+
! ! ^
! V !
! +---------+ +--------+ !
! ! OUTPUT ! ! INPUT ! !
+->! routine !-------||-------->! driver !---+
+---------+ +--------+
Şekil 1
Bu RFC, çevrimiçi RFC arşivine eklenmek üzere Ian Redfern tarafından 4/99 tarihinde makine tarafından okunabilir biçime dönüştürülmüştür.