← rfc/
╔══════════════════════════════════════════════════════════════════════════╗
RFC 282 · graphics

Grafik Toplantı Raporu

Yazar
M. A. Padlipsky
Kurum
Project MAC
Tarih
8 Aralık 1971
Durum
Network Working Group Yorum Talebi
Kanal
graphics/

| Yazar | M. A. Padlipsky | | Kurum | Project MAC | | Tarih | 8 Aralık 1971 | | Durum | Network Working Group Yorum Talebi | | RFC Numarası | 282 |

İkinci Network Graphics Group Toplantısı, 21 Kasım Pazar günü saat 18:00’de Stanford Artificial Intelligence Lab’da gerçekleştirildi. (Katılımcılar Ek bölümünde listelenmiştir.) Jim Michener toplantı başkanlığı yaptı ve ben de ya gönüllü oldum ya da gönüllü gösterildim; Karl Kelly’nin not tutma konusundaki yardımıyla kayıt sekreteri olarak görev yaptım.

Toplantı için üç ana konuyu kapsayan bir gündem üzerinde anlaşmaya varıldı:

  1. Temmuz toplantısında başlatılmış olan deneyler hakkında raporlar
  2. Network Graphics hakkında genel noktalar dile getirmek isteyen katılımcıların hazırladığı konuşmalar
  3. "ilk geçiş" niteliğinde bir grafik protokolünün tanımlanması

Raporlar verilmeden önce iki önemli konu hakkında genel bir tartışma yapıldı: "bağlam" problemi (Network bağlamında grafik bağlantıları tam olarak nasıl kuruluyor ve kimin kimin için ne yapması gerekiyor) ve "konsol türleri" olarak adlandırılabilecek konu (doğası gereği statik depolama tüpü tipi aygıtlar için ayrı bir protokol ve kendi işlemcilerine sahip doğası gereği etkileşimli yenileme tipi aygıtlar için ayrı bir protokol mü olmalı, yoksa her ikisini de kapsayan sürekli — ya da katmanlı — tek bir protokol oluşturulabilir mi).

Her iki noktanın da toplantının protokol tanımlama aşamasında akılda tutulması gerektiği belirtildi. Tek bir protokolün tercih edilir olacağı yönünde görünür bir uzlaşma oluştu ve deney raporlarına geçildi.

Deney Raporları

RAND – UCSB

RAND’den Eric Harslem ve UCSB’den Ron Stoughton, RAND Videographics terminallerinden UCSB On-Line System (OLS) kullanımı içeren deneylerini rapor ettiler. Gösterilen bir video kaydıyla da ortaya konduğu gibi deney başarılı oldu. Kullandıkları basit protokolü açıklayan bir RFC yakında yayımlanacaktır. Tartışmalarında ve RFC’de belirtildiği gibi, deneysel protokol bir Network standardı olarak önerilmemektedir.

RAND’den OLS kullanımına ek olarak, yardımcı bir deney RAND tarafında verilen tahsis boyutlarındaki (Host-to-Host Protocol anlamında) değişimlerin bağlantı üzerindeki etkisini test etti. Aynı resimlerin farklı tahsis seviyelerinde çizildiğini gösteren video kaydından, daha büyük tahsislerin belirgin biçimde daha akıcı çizim sağladığı açıkça görüldü. Maksimum tahsiste resim neredeyse tek seferde görünürken, minimum tahsiste NCP–NCP ek yükü yeterince büyük olduğundan resim parça parça ortaya çıktı.

SDC – DMCG

MIT Project MAC’in Dynamic Modeling/Computer Graphics Group’una ait PDP-10’da toplanan tablet verilerinin SDC’deki bir karakter tanıma paketine gönderilmesini amaçlayan bir deney, SDC’den Jean Saylor ve DMCG’den Jim Michener tarafından rapor edildi. Her iki uçtaki (ve aradaki) donanım/yazılım güçlüklerinden zaman dilimi kaynaklı sistem erişilebilirliği çatışmalarına kadar uzanan problemler deneyin ilerlemesini yavaşlattı; ancak bazı veri iletimleri gerçekleştirilebildi.

Illinois Multics

Sorunlarla karşılaşan bir başka çalışma da Multics Graphics System kullanılarak University of Illinois’teki bir konsolun sürülmesi girişimiydi. Bu deney Jack Bouknight (Illinois) ve Ed Meyer (Multics) tarafından rapor edildi. Multics tarafındaki bir NCP hatası ile Illinois tarafındaki bir makine değişimi birleşerek deneyin gerçekleştirilmesini engelledi.

Ara Not

Raporu sırasında Bouknight, Network’ün genel olarak grafik çalışmasını destekleyecek kadar güvenilir olup olmadığı konusunda endişesini dile getirdi. Sonraki tartışma Multics dışındaki bir ana bilgisayarın sık sık erişilemez olması üzerinde yoğunlaştığından, tarafsızlık adına bu konuda anonimliği korumanın benim yetki alanımda olduğunu düşünüyorum. Bununla birlikte, katılımcıların çoğunun Jack’in endişesini paylaştığı göz önüne alındığında tartışmanın varlığını belirtmenin saklanmasına gerek olmadığını düşünüyorum.

Oldukça kapsamlı konuşmaların ardından ortaya çıkan genel görüş şudur: Network sunucu ana bilgisayarlarının mevcut güvenilirlik düzeyi grafik çalışmasını felce uğratacak düzeyde değildir, ancak ciddi ölçüde engelleyici olabilir.

SEX – NIC

Jon Postel (UCLA) ve John Melvin (SRI), son deney raporunu sundular. Bu deney, SEX sistemindeki bir IMLAC’ı Network Information Center’da yerel bir NLS konsolu gibi görünür hale getirme girişimiydi. Deney henüz gerçekleştirilmemiştir, ancak UCLA IMLAC’larını değiştirmek için gerekli ekipmanı sipariş etmiştir.

Sunumlar

Hazırlıklı konuşma yapan konuşmacıların çoğu, muhtemelen nezaketlerinden dolayı — belki de (tehdit edilen) yanlış aktarma korkusundan — özet taleplerime olumlu yanıt verdi. Yazarların özetleri aşağıdaki bölümde tırnak işaretleri içinde verilmiştir.

Plasma Panel Display — Dave Liddle

"Owens-Illinois DS-1 terminali, ARPA aracılığıyla talepte bulunan Network kullanıcılarına sunulacaktır. Görüntü modülü OI 512×512 çizgili plazma paneldir; işlemci modemli 16-bit, 4K bir makinedir; ASCII klavye ve isteğe bağlı kaset teyp bulunur. Basit yazılım (karakter ve vektör üreteçleri vb.) sağlanacaktır. Siparişler 1 Ocak’a kadar toplanabilirse teslimatlar bu yaz başlayacaktır."

Grafik Dikkat İşleme İçin Diller — Ira Cotton

"Operatör girdilerinin bir bilgisayar grafik sisteminde işlenmesini programlamak için mevcut diller işlevsel sınıflar halinde düzenlendi ve kısaca incelendi. Bu yeteneğin çok bilgisayarlı bir grafik sisteminde (örneğin Network) sağlanmasıyla ilişkili bazı sorunlar tartışıldı ve yeni bir yaklaşım sunuldu. Univac tarafından sistemlerinden biri için uygulanan bu sistem, uzak grafik denetleyicisinde dikkat işleme yönlendirmek için yorumlayıcı olarak yürütülen bir komut dili kullanır. Dilin komutları ana hatlarıyla açıklandı ve bazı program parçaları örnek olarak gösterildi."

"Etkileşimli" Grafik Konuları — Ken Pogran

"Bu konuşmanın amacı, etkileşimli grafikler için bir Network protokolü geliştirilirken karşılaşmamız gereken bir dizi önemli konuyu gündeme getirmekti. Bu ikinci grafik toplantısındaki çalışmaların büyük bölümü 'statik' ya da 'depolama tüpü' grafikleri için bir protokol üzerine yoğunlaşmış olsa da, etkileşimli grafik protokolü geliştirme sürecinde karşılaşacağımız sorunları düşünmeye başlamamız uygundur."

"Gündeme getirilen konular şunları içeriyordu: (1) grafik etkileşiminin doğası, (2) kullanılabilecek çeşitli donanım/yazılım yapılandırmaları, (3) sunucu ve kullanıcı ana bilgisayar konumlarında gerekli hesaplama yetenekleri, (4) çok çeşitli uygulamalara uygun bir grafik veri yapısının doğası ve (5) genelleştirilmiş bir etkileşimli grafik sistemi için grafik girdilerinin niteliği ve işlenmesi."

OLS Deneyi İçin Protokol — Ron Stoughton, Eric Harslem

"RAND Videographics System’i UCSB On-Line System’e bağlamak için kullanılan bir grafik protokolünü açıklayan kısa bir sunum yapıldı. Deneyin canlı bir gösteriminin video kaydı da sunuldu. Deneyi ve protokolü ayrıntılı biçimde açıklayan bir RFC yakın gelecekte yayımlanacaktır."

Bağlantı Değerlendirmeleri — Andy Moorer (M.A.P. tarafından özetlenmiştir)

Konu kısa ve öz bir şekilde "bu şeyin nasıl çalışması gerektiği" olarak başlatıldı. Basit grafikler için (yani aygıta özgü kodların iletildiği durumlarda) Telnet Protocol kullanılmasının uygun olacağı önerildi; buna ek olarak Enter Graphics Mode, Leave Graphics Mode ve Console Type için Telnet kontrol kodlarının eklenmesi gerekecektir. Karmaşık grafikler için (yani bir ara biçimin iletildiği durumlarda) ek bir soket çifti kullanılmasının uygun olacağı önerildi.

Bağlantı Türleri — Jim Michener (M.A.P. tarafından özetlenmiştir)

Network üzerinden bağlanabilecek en az üç tür grafik aygıtı vardır: "basit" (ARDS benzeri), "akıllı" (IMLAC benzeri) ve "güçlü" (E&S benzeri). Üç tür işlem söz konusudur: uygulama paketleri (A), grafik paketleri (G) ve aygıta özgü kodlara dönüştürme (C); bu dönüşüm potansiyel olarak daha önceki RFC’lerde tartışılan "Network Standard Graphics Stream" gibi bir ara biçimden yapılabilir. Ayrıca her tür işlemin gerçekleştirilebileceği üç yer vardır: grafik aygıtının kendisi, yerel ana bilgisayar (TIP ise yardımcı olamayabilir) ve uzak bir ana bilgisayar (ya da ana bilgisayarlar).

Bu durum, desteklemek istediğimiz bağlantı türlerini gösteren bir tür 3×3×3 matris ortaya koymalıdır; ancak bunu nasıl çizeceğimi bilmiyorum.

Tüm basit aygıtlar için C işlemi başka bir yerde yapılmalıdır. Basit aygıt Network’e bir TIP aracılığıyla bağlıysa, C işlemi görünüşe göre ya A ve G’nin bulunduğu uzak ana bilgisayarda (RH1) ya da başka bir uzak ana bilgisayarda (RH2) gerçekleştirilmelidir (örneğin Data Reconfiguration Service sunan). Ayrıca C için gerekli görüşmelerin TIP adına RH1 tarafından yapılması gerekebilir. RH2 üzerinde ek bir uygulamanın (A′) ve/veya ek bir grafik paketinin (G′) bulunmasının istenmesi durumunda daha fazla karmaşıklık ortaya çıkar.

Basit aygıt Network’e tam özellikli bir yerel ana bilgisayar (LH) üzerinden bağlıysa, A, G ve C işlemlerinin her biri potansiyel olarak LH veya RH1’de — hatta RH2’de — gerçekleştirilebilir ("kırpma için bir E&S’e gönder").

Akıllı aygıtlar söz konusu olduğunda, C işlemi potansiyel olarak aygıtın kendisinde yapılabilir; ancak TIP bu tür durumları temiz bir şekilde ele almak için istenen ek soket çiftini sağlayamayabilir. Son olarak güçlü aygıtlar G işlemini dahili olarak yapabilir, ancak A ve G işlemlerini Network üzerinden gerçekleştirmek isteyebiliriz. Bu tür durumların TIP tarafından nasıl ele alınacağı yine net değildi.

Jim bu tartışmayı, toplantı protokol hattının içeriğiyle tamamen meşgul hale gelmeden önce dikkatleri protokol hattının "uçlarına" yöneltmek amacıyla sunmuştu. Biz de buna mümkün olan tek şekilde karşılık verdik.

Bağlantı Protokolü Komitesi

Bir Graphics Connection Protocol oluşturmak üzere bir komite belirlendi. Bu protokol, Telnet Protocol açısından Initial Connection Protocol’ün oynadığı role benzer bir rol üstlenecektir. Komite aksini gösteren son derece güçlü gerekçeler bulmadığı sürece Telnet bağlantıları üzerinden yalnızca aygıta özgü kodların iletilmesi gerektiği konusunda açık bir uzlaşma vardı.

Komite Michener, Bouknight, Harslem ve benden oluşmaktadır. BBN’den Will Crowther, TIP temsilini ve uzmanlığını sağlamak üzere komiteye davet edilecektir.

Grafik Kaynak Belgeleri

Protokol tanımlamasına geçmeden önce, katılımcıların çoğunun Grafik konusuna yönelik Resource Notebook benzeri belgelerin hazırlanması gerektiğini düşündüğü belirtilmelidir. Postel bu çalışmayı koordine etmek için gönüllü oldu. Ana bilgisayarlar taslaklarını ona göndermelidir; o da bunların Resource Notebook’un yeni bölümleri olarak yayımlanmasını sağlayacaktır.

Biçim konuları tartışılmadı, ancak biçimin büyük olasılıkla ana Resource Notebook bölümlerini taklit etmesi beklenmektedir. Sorularınız varsa Jon’u arayın (213-825-2368).

Protokol

Ana protokol tartışmasının başında, toplantıda üzerinde uzlaşma sağlanamayan konuları çözmek ve yıl sonuna kadar NGG’ye dağıtılacak bir protokol taslağı hazırlamak üzere bir komite kurulması konusunda anlaşmaya varıldı. Komite üyeleri Michener, Meyer, Kelly, Cotton ve Liddle’dır.

Varsayımlar

Aşağıdaki varsayımlar üzerinde anlaşmaya varıldı:

  1. Bir "sanal ekran" ve bir Standard Graphics Stream olacaktır.
  2. Orijin merkezde olacaktır.
  3. Koordinatlar işaretli, 2’nin tümleyeni kesirleridir (−0.5 ile +0.499 arası).
  4. Standard Graphics Stream başlangıçta 8-bit baytlardan oluşacaktır; koordinatlar iki bayttır. (Gerekirse daha sonra "koordinat boyutu ayarla" işleci eklenecektir.)
  5. Metin çıktısı için Network ASCII kullanılacaktır; gerekli yerlerde varsayılan olarak büyük harf kullanılacaktır. Kontrol karakterleri şimdilik site’ye özgüdür.
  6. Uygun durumlarda işleçler "mutlak", "göreli" ve "yerel" (bir alt resme göre) kiplerine sahip olacaktır.
  7. Protokol "karmaşıklık düzeyleri" temelinde düzenlenecektir: seviye 0 basit resim çizimi işleçlerini, seviye 1 bir düzey alt resim tanımı işleçlerini ("makrolar" ya da gevşek anlamda "alt programlar"), seviye 2 ise "viewport" ve "window" türü işleçleri içerecektir.

Tartışmanın özellikle grafik çıktısı üzerine yoğunlaştığına dikkat edilmelidir. Protokol Komitesi ayrıca giriş tarafı protokolü için öneriler hazırlama yetkisine de sahiptir; ancak ilk öncelik kabul edilebilir bir çıkış tarafı protokolünün formüle edilmesine verilecektir.

İşleçler

Protokol Komitesi taslağı henüz hazır olmadığından, toplantı sırasında sözdizimi ve anlambilimi uzun uzun tartışılan aşağıdaki düşük seviyeli işleçler listesi ilgi çekici olabilir:

  1. Sil ve orijine sıfırla. Bu işleç ekranın silinmesine ve ışının (0,0) sanal ekran merkez noktasına konumlandırılmasına neden olur. Yeni bir resim başlatılır.
  2. Taşı. Çizgi çizilmez; ışın belirtilen x, y konumuna yerleştirilir. göreli taşı, mutlak taşı ve yerel taşı kipleri için özel işleçler vardır.
  3. Çiz. Mevcut ışın konumundan belirtilen x, y konumuna kadar bir çizgi (mevcut "çizgi türü" ile — aşağıda 5’e bakınız) çizilir. Kipler taşı ile aynıdır. "Ekran dışı" durumunun nasıl ele alınacağı görüntüyü sağlayan ana bilgisayarın tercihine bağlıdır.
  4. Nokta. Belirtilen konumda bir nokta göster.
  5. Çizgi türü. Aksi belirtilene kadar belirtilen türde çizgiler çiz. Şu anda tanımlanan türler: düz (0), kesikli (1), noktalı (2). İstenen tür uygulanmamışsa bir alt değere varsayılan olarak düşülür. "Sil" işleminden sonra tür değiştirilene kadar düz çizgidir.
  6. Çizgi yoğunluğu. Çizgi yoğunluğunu şu şekilde talep eder: 0 = kapalı, 128 = normal, 255 = en parlak, ara değerler = uygun şekilde eşlenir. "Sil" işleminden sonra yoğunluk değiştirilene kadar normaldir.
  7. Metin. Belirtilen sayıda belirtilmiş (Net ASCII) karakterin görüntülenmesine neden olur. Son karakterden sonra ışını geri döndür (metin gösteriminden önceki konuma) ve ışını bırak (nerede kalırsa) işleçleri vardır. Boyut, görüntüleyen ana bilgisayarın "normal" kabul ettiği boyutta olacaktır. "Sağ kenar" ve ASCII kontrol karakterlerinin ele alınması şimdilik ana bilgisayara özgüdür. (Karakter boyutu işleci daha sonra tanımlanabilir.)
  8. Escape. Konsol belirtilen türdeyse, belirtilen sayıda baytı doğrudan ona iletir.

Viewport ve alt resimler için işleçler de tartışıldı. Bouknight ve Kelly, tartışılan tüm noktalar için bir BNF tanımı hazırladılar; bu tanım Protokol Komitesi taslağında yer alacaktır.

Diğer Konular

Kalan teknik tartışma, oldukça genel bir düzeyde grafik girdisi üzerineydi.

Michener, toplantıya ev sahipliği yaptığı için Andy Moorer’a katılımcıların teşekkürlerini iletti.

Cotton, bir sonraki toplantıya Nisan ortasında Washington’daki Mitre’da ev sahipliği yapmayı gönüllü olarak üstlendi. O zamana kadar bağlantı protokolü ve ilk aşama çıktı protokolü konusunda yeterli deneyim kazanmış olmayı ve bunlar hakkında "nihai" bir ifade üzerinde uzlaşmayı; ayrıca girdi tarafı üzerine yeterince düşünmüş olup bunun için bir ilk aşama protokolü belirleyebilmeyi umuyoruz (Protokol Komitesi bunu daha önce yapmayı başaramazsa).

Ek — Katılımcı Listesi

[Bu RFC, çevrimiçi RFC arşivlerine eklenmek üzere Kelly Tardif, Viagénie tarafından 10/99 tarihinde makine tarafından okunabilir biçime dönüştürülmüştür.]