broncode

[Henk Elegeert]

REPLY TO: D66 at nic.surfnet.nl

Martin Lentink wrote:

> Henk Elegeert wrote:
> <...>
>
>> Hij maakt dus geen gebruik meer van nullen en ennen (data),
>>  maar van pixel wijzigingen, en ja dan weer wel van nullen
>> en enen, maar om het (beeld)scherm aan te sturen.
>
> <...>
>
> Wat zijn pixelwijzigingen anders dan data, 1en en 0en?

Dat is ook wat ik beweer. Het gaat echter over het verschil
omdat beeld weer eens opnieuw op je scherm te krijgen. Dan
heb ik die beelden met daaraan hangende informatie niet meer
nodig.

Hoeveel, Martin? Hoeveel data heb je daar echt voor nodig.
Jan heeft die hoeveelheid terug weten brengen, als ik hem
goed begrijp.

> Waarom denk je dat die nVidia kaart van jou zoveel videomemory nodig
> heeft, en zulke vette processoren om al die wijzigingen in pixels,
> inclusief hun kleurendiepte en zo telkens te herberekenen?

Precies. De 'database' is er dus. En wordt aan het werk
gezet met data in een andere vorm.

Het gaat ook over het herhalen van beelden. Niet het 'live'
  creeren ervan. Die 'database' is aanwezig.

> Ik ben toch behoorlijk benieuwd hoe je wijzigingen in een beeld (per
> definitie een matrix van horizontale X verticale resolutie X
> kleurendiepte) over een draadje wilt sturen _zonder_ dataoverdracht, dus
> 1en en 0en....

Onmogelijk in een digitale omgeving, maar het punt is dat de
'film' zelf ook uit niet meer bestaat dan die zich
wijzigende pixel. Hij (Jan) gebruikt daar een andere matrix
voor met veel minder te verplaatsen data.

> Inderdaad gebeurt terwijl je dit leest op je computer niets anders,
> aangestuurd door je grafische kaart, die weer wordt aangestuurd door je
> videodriver die weer wordt aangestuurd door je besturingssysteem.

Kijk, en daar zijn we nu. Jan heeft die rompslomp ertussen
uit gehaalt en zich gericht op enkel die informatie die
nodig is voor je beeldscherm zelf. Onnodig je te vertellen
dat je die ook weer naar data om zou kunnen zetten, toch?

Maar dat is dan wel weer ander soortige data, als je me kunt
volgen. Van zo'n 3 GB ofzo ....

Of werkt ook je printscreen nu niet meer?

> En bij het lezen van tekst is die Videokaart inderdaad niet zo belast.

De werkelijke informatie die je nodig hebt is veel geringer
dan die nu gebezigd wordt. Ik zit tegen een witte
achtergrond aan te kijken. Slecht een BIT voor nodig.
Gecodeerd bevat die informatie genoeg.

> Maar bij bewegende beelden. zoals games, en het tonen van filmpjes wordt
> die kaart toch behoorlijk belast. En waarom? Omdat er mega veel bitjes,
> namelijk pixelwijzigingen in jouw terminologie, moeten worden rondgepompt.

Nee, je gaat weer uit van de data zoals die nu plaats vindt.
  Neem het voorbeeld van die ene bit (witte achtergrond) die
verplaats hij bij scrollen. Maar hij heeft enkel informatie
nodig waarheen en niet de hele bubs aan date zelf.

> En in tegenstelling tot hetgeen Hein eerder dacht, nl. dat er wel niet
> zoveel verschil zou zitten in een plaatje van Joris of een plaatje van
> Hein is dat voor het op het beeldscherm zetten van die pixeltjes toch
> wel degelijk het geval. Elke pixel moet een opdrachtje krijgen of ´ie
> aan of uit moet, en vaak ook nog in welke intensiteit.

Die zit in de 'database' en is bekend. Al die data is al op
de plaats van bestemming of wordt even verplaatst.

> Voor het simpele beeldschermpje van de notebook waarop ik dit tik is
> alleen al 3MB aan geheugen nodig om die beeldscherminformatie (de stand
> van die pixeltjes) bij te houden, en dan praat ik over een statische
> situatie. Alleen al het bewegen van mijn muis, en dus dat fraaie peiltje
> over het scherm (in niet tevoren te voorspellen richting!) zorgt voor de
> noodzaak van herberekening van die dataset (niet alles, toegegeven, maar
> daar houden os/videodriver al rekening mee, niks nieuws).

Gedecodeerd ziet het er totaal anders uit. Een paar pixels
veranderen slechts in één 16 x 16 blokje. bewegen is dus het
ergens anders plaatsen van je pixels. Wacht even: te
voorspellen valt dat het blokje er dadelijk precies
hetzelfde uitgaat zien, niet? Sla ik even op. Er is
nauwelijk data. Het gaat om die paar pixels en hun plaats en
kleur, intensiteit, maar gecodeerrd uiteeraard. Opnieuw dus
niet de data die er nu heen gaat.

> Ik snap van je uiteenzetting werkelijk geen duvel.

Het is een lastige Martijn. Je wordt maar even gevraagt maar
even alles te vergeten en opnieuw naar het probleem te
kijken. De kern is je beeldbuis of de vervanger(s) ervan.

> Immers het over de
> lijn sturen van opdrachten tot wijziging van een bepaalde situatie x,
> levert, hoe gecodeerd ook, dingen op als: zet nu de rechthoek van pixels
> op positie x,y aan met kleur a en intensiteit b, enz. enz. enz En dat
> tenminste 30x per seconde...

Opeenvolgend, dat is wat Jan ook noemt. En nee, niet 30 keer
per senconde. Pas als de pixel werkelijk wijzigd.

> Ook die analogie van die ober die roept "35 voor 12" gaat niet op. In
> dat geval is de originele informatie namelijk bij zowel zender als
> ontvanger reeds aanwezig.

Precies. Welke andere informatie heb je nodig voor de opbouw
van je beeldscherm als alles aanwezig is?

> Zowel Ober als kok weten heel goed wat er mee
> bedoeld wordt, en zo niet dan kunnen ze dat in de menukaart/receptenboek
> opzoeken.

In een 'database' toch wel.

> Bij een filmpje zal het als ik roep "The Matrix" wellicht bij een aantal
> onmiddelijk in hun geest beelden oproepen van die film, daarmee heb ik
> die fim nog niet op mijn schermpje.

ZO simpel is het nu ook weer niet. :)

Maar het gaat hier slechts om het 'beeld(en)' niet om de
inhoud. De essentie van het plaatje/image/beeld waar het de
(uit te wisselen) pixel informatie betreft. Die wordt
gecodeerd en volgens de (informatie in de) sleutel
gedecodeerd op je scherm gezet.

> Ik zal wel niet snappen allemaal, maar ja, ik heb nog maar 15 jaar in de
> computerbusiness gezeten.

Jan Sloot heeft er ook een tijd over gedaan, en jij wilt het
in één keer al helemaal willen begrijpen?

Het gaat ook niet om de tijd, Martin.

Het is zelfs niet uitgesloten dat het dit niet is.
Maar ik ben nog steeds optimistisch.....

Henk Elegeert

**********
Dit bericht is verzonden via de informele D66 discussielijst (D66 at nic.surfnet.nl).
Aanmelden: stuur een email naar LISTSERV at nic.surfnet.nl met in het tekstveld alleen: SUBSCRIBE D66 uwvoornaam uwachternaam
Afmelden: stuur een email naar LISTSERV at nic.surfnet.nl met in het tekstveld alleen: SIGNOFF D66
Het on-line archief is te vinden op: http://listserv.surfnet.nl/archives/d66.html
**********