---

Er jeg den eneste, der sidder med indtrykket af, at KDE2 er genial...men
langsom? Jeg bruger RH 7.2 på følgende hardware:

Epox MVP3-C2
AMD K6-2 500
256 MB ram
9.1 GB IBM HD (7200 rpm / 2 MB)
Riva TNT2 32 MB

Jeg dualbooter med Win2K, som kører helt forrygende. Ingen problemer med
hastigheden overhovedet.

Det er også galt under RH 7.1 og Mandrake.

Er det generelt at KDE (og Gnome for den sags skyld) kører langsomt, eller er
det bare min hardware, der ikke er Linux-venligt?

Kan jeg tweake et eller andet?

/Lars


--
Posted from nig.dk [194.239.235.125]
via Mailgate.ORG Server - http://www.Mailgate.ORG

---

Lars Overgaard wrote:

> Er det generelt at KDE (og Gnome for den sags skyld) kører langsomt, eller
> er det bare min hardware, der ikke er Linux-venligt?

Gnome kender jeg ikke, men KDE /er/ langsomt. Det skyldes (i sammenligningen
med Windows) X og en dårlig C++ compiler. Med RedHat 7.2 er der det yder-
ligere problem, at kernen ikke er alt for god.


> Kan jeg tweake et eller andet?

Prøv at lege lidt med hdparm for at sætte hastigheden på dine diske op.
Skift evt. til 2.4.16 kernen - muligvis med en preemption patch. Og så
kan du også prøve med det prelink tool, der ligger under /preview/SRPMS
på den anden installations CD.

-Claus

---

"Claus Rasmussen" <clr@cc-consult.dk> wrote in message
news:3c038f54$0$4865$ba624c82@nntp02.dk.telia.net...


> > Med RedHat 7.2 er der det yderligere problem, at kernen ikke er alt for god.

Okay...vil et skift til 2.4.16 betyde noget for hastigheden?

> > Kan jeg tweake et eller andet?
>
> Prøv at lege lidt med hdparm for at sætte hastigheden på dine diske op.
> Skift evt. til 2.4.16 kernen - muligvis med en preemption patch. Og så
> kan du også prøve med det prelink tool, der ligger under /preview/SRPMS
> på den anden installations CD.
>
> -Claus

Disken har allerede været udsat for hdparm, så jeg vil prøve at kigge
på den prelink-fætter, og se hvad der sker.

Tak for dit svar.

/Lars


--
Posted from nig.dk [194.239.235.125]
via Mailgate.ORG Server - http://www.Mailgate.ORG

---

Claus Rasmussen wrote:

> Prøv at lege lidt med hdparm for at sætte hastigheden på dine diske op.
> Skift evt. til 2.4.16 kernen - muligvis med en preemption patch. Og så

Preemptible er med i 2.4.14 og vel derefter.
Jeg synes bare ikke rigtigt jeg har kunnet mærke nogen forskel.

--
Jesper

---

Jesper FA <news@skydiver.dk> writes:

> Claus Rasmussen wrote:
>
> > Prøv at lege lidt med hdparm for at sætte hastigheden på dine diske op.
> > Skift evt. til 2.4.16 kernen - muligvis med en preemption patch. Og så
>
> Preemptible er med i 2.4.14 og vel derefter.
> Jeg synes bare ikke rigtigt jeg har kunnet mærke nogen forskel.

Det skulle den da helst ikke være... Ikke i vanilla kernel versionen
ihvertfald, da svjv vil hr. Torvaldsen ikke have den med.

--
Dennis
I too have always thought explanations were overkill when correcting peoples
mistake... A simple "that's wrong" has to suffice. I mean, people are always
aware why they are wrong... They just make mistakes to annoy you...

---

Dennis Haney wrote:

>> Preemptible er med i 2.4.14 og vel derefter.
>> Jeg synes bare ikke rigtigt jeg har kunnet mærke nogen forskel.
>
> Det skulle den da helst ikke være... Ikke i vanilla kernel versionen
> ihvertfald, da svjv vil hr. Torvaldsen ikke have den med.

Nææ.. Jeg sad og roede med det for nogen tid siden. Jeg mente så bare at
jeg opdagede det var med i 2.4.14, men jeg må jo have patchet det selv.

--
Jesper

---

Claus Rasmussen <clr@cc-consult.dk> writes:

> Gnome kender jeg ikke, men KDE /er/ langsomt. Det skyldes (i sammenligningen
> med Windows) X og en dårlig C++ compiler. Med RedHat 7.2 er der det yder-
^

Hvorfor mener du det?

---

Soeren Sandmann wrote:

> Claus Rasmussen <clr@cc-consult.dk> writes:
>
>> Gnome kender jeg ikke, men KDE /er/ langsomt. Det skyldes (i
>> sammenligningen med Windows) X .............................
> ^
> Hvorfor mener du det?

Fordi der er et ekstra lag som alle tegne-kommandoer skal igennem.
Det er et af argumenterne for at basere sig på frame-buffer grafik
i stedet.

Det er en almindelig mening, at X protokollen placerer sig mellem
to stole: Den er for high-level som desktop (du kan ikke få fat i
hardwaren men skal altid igennem X's abstraktionslag) og for low-level
som netværksprotokol (du skal sende aalt for mange pakker hen over
netværket).

-Claus

---

Den Tue, 27 Nov 2001 20:50:52 +0100 skrev Claus Rasmussen:
>Soeren Sandmann wrote:
>
>> Claus Rasmussen <clr@cc-consult.dk> writes:
>>
>>> Gnome kender jeg ikke, men KDE /er/ langsomt. Det skyldes (i
>>> sammenligningen med Windows) X .............................
>> ^
>> Hvorfor mener du det?
>
>Fordi der er et ekstra lag som alle tegne-kommandoer skal igennem.
>Det er et af argumenterne for at basere sig på frame-buffer grafik
>i stedet.

Framebuffer er fint til DOOM, men et normalt program har mere at bruge
vinduer, tekst, firkanter(knapper) m.m. til.

>Det er en almindelig mening, at X protokollen placerer sig mellem
>to stole:

Almindelig blandt folk der mener at windows er det eneste rigtige måske.

>Den er for high-level som desktop (du kan ikke få fat i
>hardwaren men skal altid igennem X's abstraktionslag)

For high-level som desktop? Folk plejer da nærmere at brokke sig over
at X ikke definerer hvordan widgets skal se ud, men overlader det til
tool-kit'et.

>og for low-level
>som netværksprotokol (du skal sende aalt for mange pakker hen over
>netværket).

Jeg kan ikke lige se hvordan du vil gøre den mere high-level, medmindre
du vil definere alle skærmbillederne serverside (hvem sagde 3270?).

Det eneste der kan være en ulempe netværksmæssigt, er at X-protokollen
bruger en del flere bytes pr. tegneoperation, end burde være nødvendigt
- hvilket dog kan klares ved at bruge Low Bandwidth X. Selv uden LBX
er X-protokollen stadig hurtig nok til at klare et doom-style 3D-spil
i 320x200 med ~10 fps over 10mbit, og ~25 (vist CPU'ens grænse) over
100mbit, ved brug af GGI-on-X.

Mvh
Kent
--
Det skete i de dage i november engang
at de første kataloger satte hyggen igang

---

Kent Friis wrote:

> Den Tue, 27 Nov 2001 20:50:52 +0100 skrev Claus Rasmussen:
>
>> Det er en almindelig mening, at X protokollen placerer sig mellem
>> to stole:
>
> Almindelig blandt folk der mener at windows er det eneste rigtige måske.

Jeg mener /ikke/, at Windows er den rigtige måde. Jeg mener bare, at vi
har et performance-problem, og at vi bliver nødt til at se på, hvad det
skyldes. Niveauet i X protokollen er efter min mening en af de medskyldige.


>> ..........Den er for high-level som desktop (du kan ikke få fat i
>> hardwaren men skal altid igennem X's abstraktionslag)
>
> For high-level som desktop? Folk plejer da nærmere at brokke sig over
> at X ikke definerer hvordan widgets skal se ud, men overlader det til
> tool-kit'et.

High-level i den forstand at du svæver himmelhøjt over hardwaren.


>> .....................................................og for low-level
>> som netværksprotokol (du skal sende aalt for mange pakker hen over
>> netværket).
>
> Jeg kan ikke lige se hvordan du vil gøre den mere high-level, medmindre
> du vil definere alle skærmbillederne serverside (hvem sagde 3270?).

F.eks kunne du sende en XML specifikation af en dialogboks til serveren.
Serveren ville så kende de basale operationer som man kunne udføre på
denne dialogboks. F.eks resize, tryk-på-knap, skrive-i-et-felt osv. Så
når brugeren trykkede på ok-knappen vidste serveren selv, at den skulle
vise knappen i nedtrykket tilstand og den behøvede derfor kun at sende
en knap-nr-1-trykket-ned pakke til klienten. Det er bare et eksempel.


> Det eneste der kan være en ulempe netværksmæssigt, er at X-protokollen
> bruger en del flere bytes pr. tegneoperation, end burde være nødvendigt
> - hvilket dog kan klares ved at bruge Low Bandwidth X. Selv uden LBX
> er X-protokollen stadig hurtig nok til at klare et doom-style 3D-spil
> i 320x200 med ~10 fps over 10mbit, og ~25 (vist CPU'ens grænse) over
> 100mbit, ved brug af GGI-on-X.

10 fps i 320x200 opløsning lyder ikke særligt imponerende i mine øren

Jeg ville heller ikke bruge Doom (eller lignende) som test-case. Prøv
i stedet at forestil dig en browser: For at vise en web-side skal klienten
bit-for-bit beskrive indholdet af siden overfor serveren. I stedet for
f.eks at sende web-siden i html format og bede serveren vise det i et
givet vindue.

-Claus

---

Claus Rasmussen <clr@cc-consult.dk> writes:

> Jeg mener /ikke/, at Windows er den rigtige måde. Jeg mener bare, at vi
> har et performance-problem, og at vi bliver nødt til at se på, hvad det
> skyldes. Niveauet i X protokollen er efter min mening en af de medskyldige.

Nu skal du jo have lov til at have din mening om tingene, men jeg
synes ikke at du på nogen måde har sandsynliggjort at det er mere
end blot din mening. Kunne du ikke understøtte dine påstande med
noget mere konkret? Andre der siger det samme? Egentligt studier
der retfærdiggør at man siger at det er netværksdesignet der leder
til dårlig ydelse (og ikke alle mulige andre faktorer)? Noget i
den dur kunnet det være rart at få på banen.

Det skal jo ikke være sådan at man ikke kan komme med udsagn med
mindre man har en mindre hær af forskere bag sig til at bakke det
op. Problemet i dette tilfælde er bare, synes jeg, at det er så
utroligt meget mere naturligt at skyde skylden på de vel forholdsvis
store pakker der lever oven på X, end på X selv.

(Jeg siger ikke at der ikke er ydelsesproblemer med X. Jeg siger bare
at jeg ikke synes at det er sandsynliggjort at den oprindelige
spørgers problem kann relateres hertil.)

Henning

---

Henning Niss wrote:

> Nu skal du jo have lov til at have din mening om tingene, men jeg
> synes ikke at du på nogen måde har sandsynliggjort at det er mere
> end blot din mening. Kunne du ikke understøtte dine påstande med
> noget mere konkret? Andre der siger det samme? Egentligt studier
> der retfærdiggør at man siger at det er netværksdesignet der leder
> til dårlig ydelse (og ikke alle mulige andre faktorer)? Noget i
> den dur kunnet det være rart at få på banen.

Jeg er normalt meget imod den diskussionsform, hvor ens ord ikke har vægt
med mindre man kan krydre dem med citater fra autoritative kilder. Det har
det med at drive diskussionen i jorden.

Det er en særdeles langsommelig process at gennemgå 20 siders google søg-
ninger (som jeg lige har gjort) for at finde nogle relevante links, og
hvis det var kravet hver gang, ville jeg hellere helt lade være med at
skrive. Og hvem ville vinde på det ?

Men jeg har som sagt alligevel været ude og finde lidt links til dig:

Først og fremmest bør du kigge nærmere på Berlen projektet, der er et
alternativ til X. Deres hjemmeside er her: http://www.berlin-consortium.org

De har også en direkte sammenligning af X og Berlin liggende her:
http://www2.berlin-consortium.org/wiki/html/Berlin/BerlinVsX.htm .

Specielt skriver de i artiklen om det "low-level" i X:

Like the X Window System, Berlin provides network transparency. The
difference is that Berlin uses CORBA for network transparency while X
Window System uses the X Protocol which is much lower level. So where
Berlin transmits the creation request for a button and click events on
that button, X transmits the look of the button each time it gets
moved/redisplayed after being obscured by another window plus all
events that happen inside the window the button is displayed in.

Her er en anden artikel, der beskriver performance i X. Udgangspunktet er
dog mere: "Når vi nu har X, hvad kan vi så gøre for at forhindre det i at
køre langsomt ?" end en diskussion af det hensigtsmæssige i designet i X.

Sammenholder man denne artikel, med hvad man kan finde om Berlins arkitektur
tegner der sig alligevel det mønster, som jeg beskrev: At X /er/ tungt.


> Det skal jo ikke være sådan at man ikke kan komme med udsagn med
> mindre man har en mindre hær af forskere bag sig til at bakke det
> op. Problemet i dette tilfælde er bare, synes jeg, at det er så
> utroligt meget mere naturligt at skyde skylden på de vel forholdsvis
> store pakker der lever oven på X, end på X selv.

Det var faktisk også det, jeg skrev i mit første indlæg i denne tråd:

Gnome kender jeg ikke, men KDE er langsomt. Det skyldes (i
sammenligningen med Windows) X og en dårlig C++ compiler. Med RedHat
7.2 er der det yderligere problem, at kernen ikke er alt for god.

Altså at X er en bidragyder til performanceproblemerne. Ikke at X er alt-
afgørende.

-Claus

---

Claus Rasmussen wrote:

> Her er en anden artikel, der beskriver performance i X. Udgangspunktet er
> dog mere: "Når vi nu har X, hvad kan vi så gøre for at forhindre det i at
> køre langsomt ?" end en diskussion af det hensigtsmæssige i designet i X.

Ups. Her: http://www.rahul.net/kenton/perf.html

-Claus

---

Claus Rasmussen <clr@cc-consult.dk> writes:

> Henning Niss wrote:
>
> Jeg er normalt meget imod den diskussionsform, hvor ens ord ikke har vægt
> med mindre man kan krydre dem med citater fra autoritative kilder. Det har
> det med at drive diskussionen i jorden.

Ja, som jeg skrev skal det jo ikke være sådan at man skal kunne drive
et større bibliotek sammen af kilder til at underbygge de udsagn man
kommer med. På den anden side synes jeg at du kommer med meget
kraftige generaliseringer --- derfor synes jeg du havde noget bevis-
byrde på dine skuldre.

> Det er en særdeles langsommelig process at gennemgå 20 siders google søg-
> ninger (som jeg lige har gjort) for at finde nogle relevante links, og
> hvis det var kravet hver gang, ville jeg hellere helt lade være med at
> skrive.

Tak for dit hyr med at fremskaffe kilder. Det var præcis sådan noget
jeg var ude efter. (Og hvis der ikke var mange ting at kigge efter,
ville det jo netop ikke være den "almindelige mening").

> Altså at X er en bidragyder til performanceproblemerne. Ikke at X er alt-
> afgørende.

Jeg vil dog henvise til det link som Jørgen kom med. Her var
konklusionen netop at den store bidragyder til sløvheden ved opstart
af KDE skyldes dynamisk linkning og at X stort set ikke bidrager til
det (initialisering af X og Qt andrager 1/10 af den samlede
opstartstid i det eksempel der nævnes). Desværre beskæftiger artiklen
i linket sig ikke med den generelle udførsel af KDE programmer.

Henning

---

Henning Niss wrote:

> Claus Rasmussen <clr@cc-consult.dk> writes:
>
>> Altså at X er en bidragyder til performanceproblemerne. Ikke at X er alt-
>> afgørende.
>
> Jeg vil dog henvise til det link som Jørgen kom med. Her var
> konklusionen netop at den store bidragyder til sløvheden ved opstart
> af KDE skyldes dynamisk linkning og at X stort set ikke bidrager til
> det (initialisering af X og Qt andrager 1/10 af den samlede
> opstartstid i det eksempel der nævnes). .............................

Det er lige præcist den analyse, der gør, at jeg også refererede til
gcc som en kilde til performance problemerne.


> ....................................... Desværre beskæftiger artiklen
> i linket sig ikke med den generelle udførsel af KDE programmer.

Nemlig.

-Claus

---

Claus Rasmussen <clr@cc-consult.dk> writes:

> Henning Niss wrote:
>
> > Claus Rasmussen <clr@cc-consult.dk> writes:
> >
> >> Altså at X er en bidragyder til performanceproblemerne. Ikke at X er alt-
> >> afgørende.
> >
> > Jeg vil dog henvise til det link som Jørgen kom med. Her var
> > konklusionen netop at den store bidragyder til sløvheden ved opstart
> > af KDE skyldes dynamisk linkning og at X stort set ikke bidrager til
> > det (initialisering af X og Qt andrager 1/10 af den samlede
> > opstartstid i det eksempel der nævnes). .............................
>
> Det er lige præcist den analyse, der gør, at jeg også refererede til
> gcc som en kilde til performance problemerne.

Hmm, hvad har det med gcc at gøre - det er da ld lib'et som her er problemet.
Dynamisk linking er smart rent memorymæssigt - men dæleme ikke specielt godt
når vi snakker performance/opstart.

--
Mvh. Kim Petersen /| Tlf: +4575831551 |\ Jomfru Ingefreds Vej 18
Software Engineer / | Fax: (none atm.) | \ 7100 Vejle
LSS / | Email: kim@vindinggaard.dk | \ DK - Danmark

---

Kim Petersen wrote:

> Hmm, hvad har det med gcc at gøre - det er da ld lib'et som her er
> problemet. ..............................................................

Dels er det ikke det eneste problem med gcc, dels er det jo gcc, der
genererer den kode, ld kløjs i. Løsningen på problemet ligger også i
gcc.


> .......... Dynamisk linking er smart rent memorymæssigt - men dæleme ikke
> specielt godt når vi snakker performance/opstart.

Ja, tja. Windows bruger jo også shared libraries uden at få tilsvarende
opstartsproblemer. Løsningen er også den samme, som i Windows: At finde
en måde at fortælle linkeren på, hvor de shared libraries bør ligge i
memory.

-Claus

---

Claus Rasmussen <clr@cc-consult.dk> writes:

> Kim Petersen wrote:
>
> > Hmm, hvad har det med gcc at gøre - det er da ld lib'et som her er
> > problemet. ..............................................................
>
> Dels er det ikke det eneste problem med gcc, dels er det jo gcc, der
> genererer den kode, ld kløjs i. Løsningen på problemet ligger også i
> gcc.
>
>
> > .......... Dynamisk linking er smart rent memorymæssigt - men dæleme ikke
> > specielt godt når vi snakker performance/opstart.
>
> Ja, tja. Windows bruger jo også shared libraries uden at få tilsvarende
> opstartsproblemer. Løsningen er også den samme, som i Windows: At finde
> en måde at fortælle linkeren på, hvor de shared libraries bør ligge i
> memory.

Har Windoze muligheden for at styre versioneringen af dll's? Det adderer jo
et ekstra layer i problematikken - og det er imho ikke en som man kan/må
fjerne - da du ellers ender i DOS/intel blindgyden - med bagudskompatibi-
liteten som hæmsko for udvikling.

Derudover synes jeg faktisk rigtig mange Windoze programmer har præcis samme
opstarsproblematik (indikation: bare det at du viser en reklame medens den
starter op... Eller forsøger at force brugeren til at holde det in-mem (IE og
Office)).

--
Mvh. Kim Petersen /| Tlf: +4575831551 |\ Jomfru Ingefreds Vej 18
Software Engineer / | Fax: (none atm.) | \ 7100 Vejle
LSS / | Email: kim@vindinggaard.dk | \ DK - Danmark

---

Kim Petersen wrote:

> Claus Rasmussen <clr@cc-consult.dk> writes:
>
>> Ja, tja. Windows bruger jo også shared libraries uden at få tilsvarende
>> opstartsproblemer. Løsningen er også den samme, som i Windows: At finde
>> en måde at fortælle linkeren på, hvor de shared libraries bør ligge i
>> memory.
>
> Har Windoze muligheden for at styre versioneringen af dll's? Det adderer
> jo et ekstra layer i problematikken - og det er imho ikke en som man
> kan/må fjerne - da du ellers ender i DOS/intel blindgyden - med
> bagudskompatibi- liteten som hæmsko for udvikling.

Øhh...

Lad mig lige forklare min forståelse af problemet:

Når et program loades sammen med sine shared libraries, skal der ske en
dynamisk linking. Denne dynamiske linking er ikke forskellig fra en
almindelig statisk linking andet end ved tidspunktet det sker på. Altså
at alle kald til funktioner i libraries skal have adressen på funktionen
justeret alt efter hvor i lageret det dynamiske library bliver placeret.

Problemet er så, at med C++ programmer og specielt KDE C++ programmer
kommer denne process til at tage en hulens tid, som det bliver beskrevet
i Waldo Bastians skriv.

Løsningen er, at man fortæller linkeren, at shared libraries bør placeres
på en bestemt adresse i lageret, så man allerede på compileringstidspunktet
ved, hvilke adresser librariets funktioner vil lægge sig på. Så sparer
man det langsommelige fixup af referrencerne og kan bare mappe bibliotekerne
ind i memory på den givne adresse. Det er det, Windows gør i sine DLLer.


> Derudover synes jeg faktisk rigtig mange Windoze programmer har præcis
> samme opstarsproblematik (indikation: bare det at du viser en reklame
> medens den starter op... Eller forsøger at force brugeren til at holde det
> in-mem (IE og Office)).

Men det er jo ikke sikkert, at det er den dynamiske linking, der er
problemet her. Det kunne jo være, at det ikke er et specielt effektivt
operativsystem, man bruger Windows programmer på

-Claus

---

Den Wed, 28 Nov 2001 21:03:21 +0100 skrev Claus Rasmussen:
>Kim Petersen wrote:
>
>Løsningen er, at man fortæller linkeren, at shared libraries bør placeres
>på en bestemt adresse i lageret, så man allerede på compileringstidspunktet
>ved, hvilke adresser librariets funktioner vil lægge sig på. Så sparer
>man det langsommelige fixup af referrencerne og kan bare mappe bibliotekerne
>ind i memory på den givne adresse. Det er det, Windows gør i sine DLLer.

Det vil da kræve at hver eneste version af hver eneste DLL en eller
anden idiot kunne finde på at linke samtidig skulle have sit eget
adresseområde. Hvordan løses det? Udover selvfølgelig at problemet
bliver en del mindre ved at alle programmer bare overskriver den
gamle (eller nye) version af DLL'en (aka. DLL hell).

Mvh
Kent
--
Dryp - dryp - dryp <Pfzt>
Keyboard error

---

Kent Friis wrote:

> Det vil da kræve at hver eneste version af hver eneste DLL en eller
> anden idiot kunne finde på at linke samtidig skulle have sit eget
> adresseområde. Hvordan løses det? ................................

Jeg ved ikke, hvordan det foregår på Windows, men på linux faldes der
tilbage på almindelig dynamisk linking, hvis der er blevet ændret på
shared libraries siden prelink.

Du skal sammenligne de administrative procedurer omkring prelink med
de procedurer, der allerede findes omkring ldconfig.

-Claus

---

kfr@fleggaard.dk (Kent Friis) writes:

> Det vil da kræve at hver eneste version af hver eneste DLL en eller
> anden idiot kunne finde på at linke samtidig skulle have sit eget
> adresseområde. Hvordan løses det? Udover selvfølgelig at problemet
> bliver en del mindre ved at alle programmer bare overskriver den
> gamle (eller nye) version af DLL'en (aka. DLL hell).

Plus problematikken med at de libraries du linker ind, er afhængige af
andre libraries - som måske allerede er tildelt mem-arealer - sikke et
mem-svineri [også selvom vi snakke virt-mem], da du så vil have eksem-
pelvis glibc 30 steder i den virtuelle hukommelse på grund af locations
krav. :(

--
Mvh. Kim Petersen /| Tlf: +4575831551 |\ Jomfru Ingefreds Vej 18
Software Engineer / | Fax: (none atm.) | \ 7100 Vejle
LSS / | Email: kim@vindinggaard.dk | \ DK - Danmark

---

Claus Rasmussen <clr@cc-consult.dk> writes:

> Løsningen er, at man fortæller linkeren, at shared libraries bør placeres
> på en bestemt adresse i lageret, så man allerede på compileringstidspunktet
> ved, hvilke adresser librariets funktioner vil lægge sig på. Så sparer
> man det langsommelige fixup af referrencerne og kan bare mappe bibliotekerne
> ind i memory på den givne adresse. Det er det, Windows gør i sine DLLer.

Hmm - så er det jo bare ikke dynamisk mere ? Så er det eneste du får en måde
at "dele" dine biblioteker på - ikke som under *nix - at du kan skifte/recom-
pilere dine libs - udskifte hele indmaden for den sags skyld - og stadig klare
det hele - du kan jo have diverse versioner af libraries uden problemer...

Derudover, så er der jo dynamic linking af ting som ikke er kendte på compile
tidspunkt [eks. apache DSO og mange andre].

>
> > Derudover synes jeg faktisk rigtig mange Windoze programmer har præcis
> > samme opstarsproblematik (indikation: bare det at du viser en reklame
> > medens den starter op... Eller forsøger at force brugeren til at holde det
> > in-mem (IE og Office)).
>
> Men det er jo ikke sikkert, at det er den dynamiske linking, der er
> problemet her. Det kunne jo være, at det ikke er et specielt effektivt
> operativsystem, man bruger Windows programmer på
>
> -Claus
>
>
>
>
>

--
Mvh. Kim Petersen /| Tlf: +4575831551 |\ Jomfru Ingefreds Vej 18
Software Engineer / | Fax: (none atm.) | \ 7100 Vejle
LSS / | Email: kim@vindinggaard.dk | \ DK - Danmark

---

Den Wed, 28 Nov 2001 11:36:29 +0100 skrev Claus Rasmussen:
>Kent Friis wrote:
>
>> Den Tue, 27 Nov 2001 20:50:52 +0100 skrev Claus Rasmussen:
>>
>>> Det er en almindelig mening, at X protokollen placerer sig mellem
>>> to stole:
>>
>> Almindelig blandt folk der mener at windows er det eneste rigtige måske.
>
>Jeg mener /ikke/, at Windows er den rigtige måde. Jeg mener bare, at vi
>har et performance-problem, og at vi bliver nødt til at se på, hvad det
>skyldes. Niveauet i X protokollen er efter min mening en af de medskyldige.

Normalt tæver min 600 MhZ linux-maskine med fvwm2 herhjemme altså min
850 MhZ W2k maskine på arbejdet big time.

>>> ..........Den er for high-level som desktop (du kan ikke få fat i
>>> hardwaren men skal altid igennem X's abstraktionslag)
>>
>> For high-level som desktop? Folk plejer da nærmere at brokke sig over
>> at X ikke definerer hvordan widgets skal se ud, men overlader det til
>> tool-kit'et.
>
>High-level i den forstand at du svæver himmelhøjt over hardwaren.

Det gør windows skam også i normale tilfælde. Det er kun spil der har
nogen fordel af at gå så tæt på hardwaren som muligt - af samme grund
skulle mange spil førhen have kryds i "kræver MS-DOS tilstand", hvis
man kørte dem under windows.

>>> .....................................................og for low-level
>>> som netværksprotokol (du skal sende aalt for mange pakker hen over
>>> netværket).
>>
>> Jeg kan ikke lige se hvordan du vil gøre den mere high-level, medmindre
>> du vil definere alle skærmbillederne serverside (hvem sagde 3270?).
>
>F.eks kunne du sende en XML specifikation af en dialogboks til serveren.

Yikes, hvorfor lige XML?

De fleste formater er enten binære, og derved komplet ulæselige for
mennesker, eller også er de tekst-baserede, og svære at parse for en
computer.

XML kombinerer så begge ulemperne, og er både (næsten) komplet
ulæseligt, og et helvede at parse for en computer.

>Serveren ville så kende de basale operationer som man kunne udføre på
>denne dialogboks. F.eks resize, tryk-på-knap, skrive-i-et-felt osv. Så
>når brugeren trykkede på ok-knappen vidste serveren selv, at den skulle
>vise knappen i nedtrykket tilstand og den behøvede derfor kun at sende
>en knap-nr-1-trykket-ned pakke til klienten. Det er bare et eksempel.

3270 kommentaren var faktisk ret godt ramt. Det er teknologi der var
populært på *gamle* IBM Mainframes.

>> Det eneste der kan være en ulempe netværksmæssigt, er at X-protokollen
>> bruger en del flere bytes pr. tegneoperation, end burde være nødvendigt
>> - hvilket dog kan klares ved at bruge Low Bandwidth X. Selv uden LBX
>> er X-protokollen stadig hurtig nok til at klare et doom-style 3D-spil
>> i 320x200 med ~10 fps over 10mbit, og ~25 (vist CPU'ens grænse) over
>> 100mbit, ved brug af GGI-on-X.
>
>10 fps i 320x200 opløsning lyder ikke særligt imponerende i mine øren

Det er 10mbit heller ikke. Jeg *har* prøvet at sidde og kopiere Quake3
over et 10mbit netværk. De andre havde fundet et nyt spil inden jeg
var halvt færdig.

>Jeg ville heller ikke bruge Doom (eller lignende) som test-case. Prøv
>i stedet at forestil dig en browser: For at vise en web-side skal klienten
>bit-for-bit beskrive indholdet af siden overfor serveren. I stedet for
>f.eks at sende web-siden i html format og bede serveren vise det i et
>givet vindue.

Du burde surfe lidt mindre på de sider der har flere billeder end
tekst

Forøvrigt skal du jo stadig overføre billederne, medmindre du bare vil
give X-serveren en <IMG SRC="http://www.goatse.cx/hello.jpg">, og så
lade den downloade billedet.

Forøvrigt så er tricket med at integrere browseren i OS'et allerede
forsøgt.

Mvh
Kent
--
Dryp - dryp - dryp <Pfzt>
Keyboard error

---

Kent Friis wrote:

[...]

>>High-level i den forstand at du svæver himmelhøjt over hardwaren.
>
> Det gør windows skam også i normale tilfælde. Det er kun spil der har
> nogen fordel af at gå så tæt på hardwaren som muligt - af samme grund
> skulle mange spil førhen have kryds i "kræver MS-DOS tilstand", hvis
> man kørte dem under windows.

Ja men X er jo det laveste niveau, man kan implementere noget som helst
på. At implementere KDE på X svarer jo til at implementere Windows på
Windows, og det kan jeg ikke forestille mig vil være en fornøjelse at
køre på.

[...]

>>F.eks kunne du sende en XML specifikation af en dialogboks til serveren.
>
> Yikes, hvorfor lige XML?

Fordi KDE allerede i dag specificerer deres vinduer i XML. Vil du ændre
layoutet af en dialogboks, gør du det i en XML fil.


> De fleste formater er enten binære, og derved komplet ulæselige for
> mennesker, eller også er de tekst-baserede, og svære at parse for en
> computer.
>
> XML kombinerer så begge ulemperne, og er både (næsten) komplet
> ulæseligt, og et helvede at parse for en computer.

Jeg er faktisk ikke uenig. XML er et stygt format, men det har altså
den kolossale fordel, at det er et standard format, der kan porteres
overalt.

Det er en /ernorm/ lettelse hvis man er flere grupper/firmaer, der
arbejder sammen om et projekt, at man kan sige, at al filudveksling
sker via XML. Man slipper (næsten) for det sædvanlige brok med
utilstrækkelige eller ændrede specifikationer af filformatet. Og parsere
er der masser af (men allesammen med et umuligt interface .


>>Serveren ville så kende de basale operationer som man kunne udføre på
>>denne dialogboks. F.eks resize, tryk-på-knap, skrive-i-et-felt osv. Så
>>når brugeren trykkede på ok-knappen vidste serveren selv, at den skulle
>>vise knappen i nedtrykket tilstand og den behøvede derfor kun at sende
>>en knap-nr-1-trykket-ned pakke til klienten. Det er bare et eksempel.
>
> 3270 kommentaren var faktisk ret godt ramt. Det er teknologi der var
> populært på *gamle* IBM Mainframes.

Vidste du at 8-bits bytes først blev implementeret på S360 ?

Men prøv at kigge den Berlin vs. X artikel jeg gav en link til et andet
sted i tråden. Der beskrives netop sådan et skema.

[...]

>> Jeg ville heller ikke bruge Doom (eller lignende) som test-case. Prøv
>> i stedet at forestil dig en browser: For at vise en web-side skal
>> klienten bit-for-bit beskrive indholdet af siden overfor serveren. I
>> stedet for f.eks at sende web-siden i html format og bede serveren
>> vise det i et givet vindue.
>
> Du burde surfe lidt mindre på de sider der har flere billeder end
> tekst

Det er omvendt: Det er på tekstsiderne, at X koster performance i forhold
til den protokol, jeg skitserede.


> Forøvrigt skal du jo stadig overføre billederne, medmindre du bare vil
> give X-serveren en <IMG SRC="http://www.goatse.cx/hello.jpg">, og så
> lade den downloade billedet.

Jeg vil næsten gætte på, at det, der sker, når et billede skal vises,
er, at klienten først pakker .jpg filen ud i et bitmap format, som så
sendes over nettet til serveren (muligvis komprimeret). Dvs. endnu et
overhead.

[...]

> Forøvrigt så er tricket med at integrere browseren i OS'et allerede
> forsøgt.

Hahaha

-Claus

---

Den Wed, 28 Nov 2001 20:13:05 +0100 skrev Claus Rasmussen:
>Kent Friis wrote:
>
>[...]
>
>>>High-level i den forstand at du svæver himmelhøjt over hardwaren.
>>
>> Det gør windows skam også i normale tilfælde. Det er kun spil der har
>> nogen fordel af at gå så tæt på hardwaren som muligt - af samme grund
>> skulle mange spil førhen have kryds i "kræver MS-DOS tilstand", hvis
>> man kørte dem under windows.
>
>Ja men X er jo det laveste niveau, man kan implementere noget som helst
>på.

Der er da også både frame-bufferen og svgalib, hvis man absolut skal
have mere eller mindre direkte adgang til hardwaren.

>At implementere KDE på X svarer jo til at implementere Windows på
>Windows, og det kan jeg ikke forestille mig vil være en fornøjelse at
>køre på.

Pjat, det svarer til at implementere explorer.exe (ikke iexplore) oven
på kernel32.dll

>[...]
>
>>>F.eks kunne du sende en XML specifikation af en dialogboks til serveren.
>>
>> Yikes, hvorfor lige XML?
>
>Fordi KDE allerede i dag specificerer deres vinduer i XML. Vil du ændre
>layoutet af en dialogboks, gør du det i en XML fil.

Det er eddermame godt jeg ikke kører KDE. Jeg får sg* nok af det
XML-helvede på arbejdet.

>> De fleste formater er enten binære, og derved komplet ulæselige for
>> mennesker, eller også er de tekst-baserede, og svære at parse for en
>> computer.
>>
>> XML kombinerer så begge ulemperne, og er både (næsten) komplet
>> ulæseligt, og et helvede at parse for en computer.
>
>Jeg er faktisk ikke uenig. XML er et stygt format, men det har altså
>den kolossale fordel, at det er et standard format, der kan porteres
>overalt.

Det er ascii også. Eller for den sags skyld at en byte er 8 bits.

Fordelen/ulempen ved den slags standarder er at de ikke definerer ret
meget, så bare fordi to programmer begge bruger XML, så er chancen for
at de kan tale sammen stadig meget lav.

>Det er en /ernorm/ lettelse hvis man er flere grupper/firmaer, der
>arbejder sammen om et projekt, at man kan sige, at al filudveksling
>sker via XML. Man slipper (næsten) for det sædvanlige brok med
>utilstrækkelige eller ændrede specifikationer af filformatet. Og parsere
>er der masser af (men allesammen med et umuligt interface .
>
>>>Serveren ville så kende de basale operationer som man kunne udføre på
>>>denne dialogboks. F.eks resize, tryk-på-knap, skrive-i-et-felt osv. Så
>>>når brugeren trykkede på ok-knappen vidste serveren selv, at den skulle
>>>vise knappen i nedtrykket tilstand og den behøvede derfor kun at sende
>>>en knap-nr-1-trykket-ned pakke til klienten. Det er bare et eksempel.
>>
>> 3270 kommentaren var faktisk ret godt ramt. Det er teknologi der var
>> populært på *gamle* IBM Mainframes.
>
>Vidste du at 8-bits bytes først blev implementeret på S360 ?

Nope. Relevans?

>Men prøv at kigge den Berlin vs. X artikel jeg gav en link til et andet
>sted i tråden. Der beskrives netop sådan et skema.

Jeg har læst lidt om berlin engang. Og allerede dengang syntes jeg ikke
det virkede interessant. Din beskrivelse har bare bekræftet mit valg
den gang - Berlin er ikke noget jeg gider bruge tid på.

>>> Jeg ville heller ikke bruge Doom (eller lignende) som test-case. Prøv
>>> i stedet at forestil dig en browser: For at vise en web-side skal
>>> klienten bit-for-bit beskrive indholdet af siden overfor serveren. I
>>> stedet for f.eks at sende web-siden i html format og bede serveren
>>> vise det i et givet vindue.
>>
>> Du burde surfe lidt mindre på de sider der har flere billeder end
>> tekst
>
>Det er omvendt: Det er på tekstsiderne, at X koster performance i forhold
>til den protokol, jeg skitserede.

Browseren fortæller da netop bare X-serveren hvor teksten skal placeres,
og hvad der skal stå. Det er derfor programmerne ser meget underlige ud
hvis man sidder på en X-Terminal med en to-tre indbyggede fonte, og ikke
har angivet nogen font-server.

Hvis browseren sender fonte som bitmaps, så er det helt klart en fejl
i browseren.

>> Forøvrigt skal du jo stadig overføre billederne, medmindre du bare vil
>> give X-serveren en <IMG SRC="http://www.goatse.cx/hello.jpg">, og så
>> lade den downloade billedet.
>
>Jeg vil næsten gætte på, at det, der sker, når et billede skal vises,
>er, at klienten først pakker .jpg filen ud i et bitmap format, som så
>sendes over nettet til serveren (muligvis komprimeret). Dvs. endnu et
>overhead.

Til gengæld sendes billedet kun EN gang, og bliver så liggende på
Xserveren indtil klienten giver besked om at det ikke skal bruges
mere. Så når man scroller op og ned, kan klienten nøjes med at be
serveren tegne billedet på den nye position.

Mvh
Kent
--
Dryp - dryp - dryp <Pfzt>
Keyboard error

---

Kent Friis wrote:

[...]

>>>>F.eks kunne du sende en XML specifikation af en dialogboks til serveren.
>>>
>>> Yikes, hvorfor lige XML?
>>
>>Fordi KDE allerede i dag specificerer deres vinduer i XML. Vil du ændre
>>layoutet af en dialogboks, gør du det i en XML fil.
>
> Det er eddermame godt jeg ikke kører KDE. Jeg får sg* nok af det
> XML-helvede på arbejdet.

Hehe...

[...]

>>Jeg er faktisk ikke uenig. XML er et stygt format, men det har altså
>>den kolossale fordel, at det er et standard format, der kan porteres
>>overalt.
>
> Det er ascii også. Eller for den sags skyld at en byte er 8 bits.

Ohh... Så har du aldrig arbejdet op imod IBM mainframes. EBCDIC format...

For slet ikke at tale om forskellige tegnsæt. Eller formattering. Og
slutter en linie nu med \r\n eller bare \n. Eller hvad sker der hvis
der ikke er en newline på sidste linie. Og er tab-tegn tilladt ?

Alle disse spørgsmål besvares ved at vælge at bruge XML. Og /det/ er
fedt.


> Fordelen/ulempen ved den slags standarder er at de ikke definerer ret
> meget, så bare fordi to programmer begge bruger XML, så er chancen for
> at de kan tale sammen stadig meget lav.

Det har du så til gengæld ret i.

[...]

>>> 3270 kommentaren var faktisk ret godt ramt. Det er teknologi der var
>>> populært på *gamle* IBM Mainframes.
>>
>>Vidste du at 8-bits bytes først blev implementeret på S360 ?
>
> Nope. Relevans?

Samme relevans som din 3270 henvisning. Gammel teknologi er ikke nødven-
digvis dårlig teknologi. Faktisk har man set den samme teknologi komme
og gå flere gange. F.eks dumme terminaler der i den seneste reinkarnation
nu hedder "thin clients".

[...]

> Browseren fortæller da netop bare X-serveren hvor teksten skal placeres,
> og hvad der skal stå. Det er derfor programmerne ser meget underlige ud
> hvis man sidder på en X-Terminal med en to-tre indbyggede fonte, og ikke
> har angivet nogen font-server.

Du har vist ret.

[...]

>>Jeg vil næsten gætte på, at det, der sker, når et billede skal vises,
>>er, at klienten først pakker .jpg filen ud i et bitmap format, som så
>>sendes over nettet til serveren (muligvis komprimeret). Dvs. endnu et
>>overhead.
>
> Til gengæld sendes billedet kun EN gang, og bliver så liggende på
> Xserveren indtil klienten giver besked om at det ikke skal bruges
> mere. Så når man scroller op og ned, kan klienten nøjes med at be
> serveren tegne billedet på den nye position.

Ja men du får en rundgang på netværket. Hver gang du flytter scollbar'en
op/ned skal der sendes en pakke frem og tilbage mellem klient og server.

-Claus

---

Den Wed, 28 Nov 2001 20:54:01 +0100 skrev Claus Rasmussen:
>Kent Friis wrote:
>
>[...]
>
>>>>>F.eks kunne du sende en XML specifikation af en dialogboks til serveren.
>>>>
>>>> Yikes, hvorfor lige XML?
>>>
>>>Fordi KDE allerede i dag specificerer deres vinduer i XML. Vil du ændre
>>>layoutet af en dialogboks, gør du det i en XML fil.
>>
>> Det er eddermame godt jeg ikke kører KDE. Jeg får sg* nok af det
>> XML-helvede på arbejdet.
>
>Hehe...
>
>[...]
>
>>>Jeg er faktisk ikke uenig. XML er et stygt format, men det har altså
>>>den kolossale fordel, at det er et standard format, der kan porteres
>>>overalt.
>>
>> Det er ascii også. Eller for den sags skyld at en byte er 8 bits.
>
>Ohh... Så har du aldrig arbejdet op imod IBM mainframes. EBCDIC format...

Nu findes der jo så mange forskellige standarder at vælge imellem.

Ascii løser ikke problemet med at kommunikere med EBCDIC maskiner, lige
så vel som XML ikke løser problemet med at kommunikere med systemer
der ikke bruger XML.

>For slet ikke at tale om forskellige tegnsæt. Eller formattering. Og
>slutter en linie nu med \r\n eller bare \n. Eller hvad sker der hvis
>der ikke er en newline på sidste linie. Og er tab-tegn tilladt ?
>
>Alle disse spørgsmål besvares ved at vælge at bruge XML. Og /det/ er
>fedt.

Det kunne besvares lige så nemt ved at definere en simpel standard, som
også er nem at kode.

>>>> 3270 kommentaren var faktisk ret godt ramt. Det er teknologi der var
>>>> populært på *gamle* IBM Mainframes.
>>>
>>>Vidste du at 8-bits bytes først blev implementeret på S360 ?
>>
>> Nope. Relevans?
>
>Samme relevans som din 3270 henvisning. Gammel teknologi er ikke nødven-
>digvis dårlig teknologi. Faktisk har man set den samme teknologi komme
>og gå flere gange. F.eks dumme terminaler der i den seneste reinkarnation
>nu hedder "thin clients".

Jeg har ikke noget imod dumme terminaler. Men systemer hvor felter,
knapper m.m. er defineret på "terminalen" har et problem så snart
man finder på et felt der er lidt anderledes.

>> Browseren fortæller da netop bare X-serveren hvor teksten skal placeres,
>> og hvad der skal stå. Det er derfor programmerne ser meget underlige ud
>> hvis man sidder på en X-Terminal med en to-tre indbyggede fonte, og ikke
>> har angivet nogen font-server.
>
>Du har vist ret.



>>>Jeg vil næsten gætte på, at det, der sker, når et billede skal vises,
>>>er, at klienten først pakker .jpg filen ud i et bitmap format, som så
>>>sendes over nettet til serveren (muligvis komprimeret). Dvs. endnu et
>>>overhead.
>>
>> Til gengæld sendes billedet kun EN gang, og bliver så liggende på
>> Xserveren indtil klienten giver besked om at det ikke skal bruges
>> mere. Så når man scroller op og ned, kan klienten nøjes med at be
>> serveren tegne billedet på den nye position.
>
>Ja men du får en rundgang på netværket. Hver gang du flytter scollbar'en
>op/ned skal der sendes en pakke frem og tilbage mellem klient og server.

Det kan du kun undgå ved at genindføre 3270'erne. Og selv der vil du
komme ind i et problem den dag klientens scroll-buffer ikke er stor
nok (Jeg er lidt i tvivl om det er et reelt problem).

Mvh
Kent
--
Dryp - dryp - dryp <Pfzt>
Keyboard error

---

kfr@fleggaard.dk (Kent Friis) writes:

> Den Wed, 28 Nov 2001 20:54:01 +0100 skrev Claus Rasmussen:
> >Kent Friis wrote:
>
> Jeg har ikke noget imod dumme terminaler. Men systemer hvor felter,
> knapper m.m. er defineret på "terminalen" har et problem så snart
> man finder på et felt der er lidt anderledes.

Hmm, det kommer vel ganske og aldeles an på hvor striks din definition og
protokol er [SEND define button SEND define shape SEND bitmap SEND define
as button(name,state)] - nu har du et standard element defineret på din ter-
minal [naturligvis bør der være mere].

Dette burde kunne gøres oven på X med extensions [hvis det ikke allerede er
muligt].

--
Mvh. Kim Petersen /| Tlf: +4575831551 |\ Jomfru Ingefreds Vej 18
Software Engineer / | Fax: (none atm.) | \ 7100 Vejle
LSS / | Email: kim@vindinggaard.dk | \ DK - Danmark

---

Den 28 Nov 2001 22:05:52 +0100 skrev Kim Petersen:
>kfr@fleggaard.dk (Kent Friis) writes:
>
>> Den Wed, 28 Nov 2001 20:54:01 +0100 skrev Claus Rasmussen:
>> >Kent Friis wrote:
>>
>> Jeg har ikke noget imod dumme terminaler. Men systemer hvor felter,
>> knapper m.m. er defineret på "terminalen" har et problem så snart
>> man finder på et felt der er lidt anderledes.
>
>Hmm, det kommer vel ganske og aldeles an på hvor striks din definition og
>protokol er [SEND define button SEND define shape SEND bitmap SEND define
>as button(name,state)] - nu har du et standard element defineret på din ter-
>minal [naturligvis bør der være mere].

Prøv at forestille dig et alm. indtastningsfelt, som håndteres på
Xserveren. Der bliver altså ikke sendt noget til klienten, før
brugeren har udfyldt hele skærmbilledet, og trykker OK. Så er der
pludselig en der skal bruge et password-indtastningsfelt der skriver
stjerner. Da det ikke er defineret i protokollen (find selv et bedre
eksempel), skal hele programmet pludselig skrives om til at gøre det
i klienten i stedet.

Mvh
Kent
--
Dryp - dryp - dryp <Pfzt>
Keyboard error

---

kfr@fleggaard.dk (Kent Friis) writes:
> Den 28 Nov 2001 22:05:52 +0100 skrev Kim Petersen:
> >
> >Hmm, det kommer vel ganske og aldeles an på hvor striks din definition og
> >protokol er [SEND define button SEND define shape SEND bitmap SEND define
> >as button(name,state)] - nu har du et standard element defineret på din ter-
> >minal [naturligvis bør der være mere].
>
> Prøv at forestille dig et alm. indtastningsfelt, som håndteres på
> Xserveren. Der bliver altså ikke sendt noget til klienten, før
> brugeren har udfyldt hele skærmbilledet, og trykker OK. Så er der
> pludselig en der skal bruge et password-indtastningsfelt der skriver
> stjerner. Da det ikke er defineret i protokollen (find selv et bedre
> eksempel), skal hele programmet pludselig skrives om til at gøre det
> i klienten i stedet.

Absolut ikke - du definerer det samme som normalt i en GUI - du behøver
ikke at have *alt* ude på terminalen - men du kunne definere og håndtere
det meste af draw,redraw på objekter på serveren [X] principielt kan du
det allerede idag - der er bare ikke specielt høje abstraktioner [eg.
så kan du sætte vinduer til at være mappet på terminalen etc.]

Jeg forsøger ikke at appelere til at event-response delen skal ligge der-
ude - det er ikke X's opgave [det kan man i øvrigt løse med en java-engi-
ne eller python samme - på den - her vil du også [ihvertfald med et for-
tolket sprog] have muligheden for at uploade special elementer].

--
Mvh. Kim Petersen /| Tlf: +4575831551 |\ Jomfru Ingefreds Vej 18
Software Engineer / | Fax: (none atm.) | \ 7100 Vejle
LSS / | Email: kim@vindinggaard.dk | \ DK - Danmark

---

Den 28 Nov 2001 23:42:14 +0100 skrev Kim Petersen:
>kfr@fleggaard.dk (Kent Friis) writes:
>> Den 28 Nov 2001 22:05:52 +0100 skrev Kim Petersen:
>> >
>> >Hmm, det kommer vel ganske og aldeles an på hvor striks din definition og
>> >protokol er [SEND define button SEND define shape SEND bitmap SEND define
>> >as button(name,state)] - nu har du et standard element defineret på din ter-
>> >minal [naturligvis bør der være mere].
>>
>> Prøv at forestille dig et alm. indtastningsfelt, som håndteres på
>> Xserveren. Der bliver altså ikke sendt noget til klienten, før
>> brugeren har udfyldt hele skærmbilledet, og trykker OK. Så er der
>> pludselig en der skal bruge et password-indtastningsfelt der skriver
>> stjerner. Da det ikke er defineret i protokollen (find selv et bedre
>> eksempel), skal hele programmet pludselig skrives om til at gøre det
>> i klienten i stedet.
>
>Absolut ikke - du definerer det samme som normalt i en GUI - du behøver
>ikke at have *alt* ude på terminalen - men du kunne definere og håndtere
>det meste af draw,redraw på objekter på serveren [X] principielt kan du
>det allerede idag - der er bare ikke specielt høje abstraktioner [eg.
>så kan du sætte vinduer til at være mappet på terminalen etc.]

Vil du ikke give mig ret i, at klienten i stedet for:
S: Text: Password
S: Textbox: 10
M: "mitpassword"

pludselig selv skal til at styre det, i retning af:
S: Text: Passwrd
S: Firkant: (100,100) (200,130)
M: "m"
S: "*"
M: "i"
S: "*"
M: "t"
S: "*"...

- altså programmet skal skrives om til at gøre det i klienten i stedet.

>Jeg forsøger ikke at appelere til at event-response delen skal ligge der-
>ude - det er ikke X's opgave [det kan man i øvrigt løse med en java-engi-
>ne eller python samme - på den - her vil du også [ihvertfald med et for-
>tolket sprog] have muligheden for at uploade special elementer].

Øh? Jeg tror lige du bliver nødt til at forklare hvad du mener...

Mvh
Kent
--
Dryp - dryp - dryp <Pfzt>
Keyboard error

---

kfr@fleggaard.dk (Kent Friis) writes:
>
> Vil du ikke give mig ret i, at klienten i stedet for:
> S: Text: Password
> S: Textbox: 10
> M: "mitpassword"
>
> pludselig selv skal til at styre det, i retning af:
> S: Text: Passwrd
> S: Firkant: (100,100) (200,130)
> M: "m"
> S: "*"
> M: "i"
> S: "*"
> M: "t"
> S: "*"...

Yip - men det er jo det du gør under alle omstændigheder i X... Det som jeg
snakkede om - var at du lagde muligheder for højere niveau grafiske elementer
over på terminalen - eg du definerer en firkant til input til at være tegnet
på en bestemt måde - du definerer font for feltet - og sender data til det -
nu skal X når den opdaterer feltet *ikke* forespørge programmet.
[basalt er dette vel en flytning af en del af windowmanager/gui delen til
terminalen - men tegningen og opdateringen af skærmen kommer tættere på
hardwaren og du mister ikke netværksmodellen.]

> - altså programmet skal skrives om til at gøre det i klienten i stedet.

Ja, noget af det... men alt dette ligger allerede i klienterne. Vi snakker om
at flytte abstraktion fra klienten til serveren.
>
> >Jeg forsøger ikke at appelere til at event-response delen skal ligge der-
> >ude - det er ikke X's opgave [det kan man i øvrigt løse med en java-engi-
> >ne eller python samme - på den - her vil du også [ihvertfald med et for-
> >tolket sprog] have muligheden for at uploade special elementer].
>
> Øh? Jeg tror lige du bliver nødt til at forklare hvad du mener...

Event-response (server:KEYPRESS('m') - client:SEND('*'))

Det andet var et eksempel på hvordan du også kunne flytte denne del over på
klienten - nemlig ved at have en fortolker på denne - feltet er for dit pro-
gram først interessant når det er udfyldt [i de fleste tilfælde], så løsningen
ville være:

1) forespørg om klienten tilbyder password-felt
2) hvis ikke - så upload en java/python stump til at løse dette
3) bed klienten om at lave et password-felt på (100,200) m. 30 chars
[du modtager et windowid - som du så kan forespørge eller modtage
mere generelle events fra]

princippet er det samme som thin clients - ikke?

Og du burde kunne indlægge dette som extention til X.

--
Mvh. Kim Petersen /| Tlf: +4575831551 |\ Jomfru Ingefreds Vej 18
Software Engineer / | Fax: (none atm.) | \ 7100 Vejle
LSS / | Email: kim@vindinggaard.dk | \ DK - Danmark

---

Den 29 Nov 2001 17:15:47 +0100 skrev Kim Petersen:
>kfr@fleggaard.dk (Kent Friis) writes:
>>
>> Vil du ikke give mig ret i, at klienten i stedet for:
>> S: Text: Password
>> S: Textbox: 10
>> M: "mitpassword"
>>
>> pludselig selv skal til at styre det, i retning af:
>> S: Text: Passwrd
>> S: Firkant: (100,100) (200,130)
>> M: "m"
>> S: "*"
>> M: "i"
>> S: "*"
>> M: "t"
>> S: "*"...
>
>Yip - men det er jo det du gør under alle omstændigheder i X... Det som jeg
>snakkede om - var at du lagde muligheder for højere niveau grafiske elementer
>over på terminalen - eg du definerer en firkant til input til at være tegnet
>på en bestemt måde - du definerer font for feltet - og sender data til det -
>nu skal X når den opdaterer feltet *ikke* forespørge programmet.
>[basalt er dette vel en flytning af en del af windowmanager/gui delen til
> terminalen - men tegningen og opdateringen af skærmen kommer tættere på
> hardwaren og du mister ikke netværksmodellen.]
>
>> - altså programmet skal skrives om til at gøre det i klienten i stedet.
>
>Ja, noget af det... men alt dette ligger allerede i klienterne. Vi snakker om
>at flytte abstraktion fra klienten til serveren.

Det gælder kun for eksisterende programmer. Nye programmer skrevet til
din model, vil skulle ud i en større omskrivning, hvis man pludselig
finder på en lille ændring der gør at man ikke kan bruge de indbyggede
features.

>> >Jeg forsøger ikke at appelere til at event-response delen skal ligge der-
>> >ude - det er ikke X's opgave [det kan man i øvrigt løse med en java-engi-
>> >ne eller python samme - på den - her vil du også [ihvertfald med et for-
>> >tolket sprog] have muligheden for at uploade special elementer].
>>
>> Øh? Jeg tror lige du bliver nødt til at forklare hvad du mener...
>
>Event-response (server:KEYPRESS('m') - client:SEND('*'))
>
>Det andet var et eksempel på hvordan du også kunne flytte denne del over på
>klienten - nemlig ved at have en fortolker på denne - feltet er for dit pro-
>gram først interessant når det er udfyldt [i de fleste tilfælde], så løsningen
>ville være:
>
> 1) forespørg om klienten tilbyder password-felt
> 2) hvis ikke - så upload en java/python stump til at løse dette

NC'er er en uddød race. Selv SUN laver SunRay terminaler i stedet (og
de er endnu mere lowlevel - der kører X-serveren på host-maskinen.

> 3) bed klienten om at lave et password-felt på (100,200) m. 30 chars
> [du modtager et windowid - som du så kan forespørge eller modtage
> mere generelle events fra]
>
>princippet er det samme som thin clients - ikke?
>
>Og du burde kunne indlægge dette som extention til X.

Ved nærmere eftertanke - er det ikke det Display Postscript gør?
Programmeringssproget er godt nok et andet...

Mvh
Kent
--
Dryp - dryp - dryp <Pfzt>
Keyboard error

---

kfr@fleggaard.dk (Kent Friis) writes:

> Den 29 Nov 2001 17:15:47 +0100 skrev Kim Petersen:
> >kfr@fleggaard.dk (Kent Friis) writes:
> >
> >> - altså programmet skal skrives om til at gøre det i klienten i stedet.
> >
> >Ja, noget af det... men alt dette ligger allerede i klienterne. Vi snakker om
> >at flytte abstraktion fra klienten til serveren.
>
> Det gælder kun for eksisterende programmer. Nye programmer skrevet til
> din model, vil skulle ud i en større omskrivning, hvis man pludselig
> finder på en lille ændring der gør at man ikke kan bruge de indbyggede
> features.

Nej - grafik er grafik - det vi snakker om er at du frit på serveren (terminalen)
kan definere bestemte sekvenser/grupper af grafik til højere level abstraktion.

Eksemplet er: [definer box, tegn box inden i [3 pixels forskudt], farvelæg ...]
[Tænk logo skildpadde grafik - hvis det hjælper - du definerer for serveren
nogle højere niveau grafiske elementer]

Hvis programmet ændres - så ændrer det jo ikke på at ovenstående er hurtigere
at udføre på serveren - det er jo bare at ændre på definitionerne - eller til-
føje.

>
> >> >Jeg forsøger ikke at appelere til at event-response delen skal ligge der-
> >> >ude - det er ikke X's opgave [det kan man i øvrigt løse med en java-engi-
> >> >ne eller python samme - på den - her vil du også [ihvertfald med et for-
> >> >tolket sprog] have muligheden for at uploade special elementer].
> >>
> >> Øh? Jeg tror lige du bliver nødt til at forklare hvad du mener...
> >
> >Event-response (server:KEYPRESS('m') - client:SEND('*'))
> >
> >Det andet var et eksempel på hvordan du også kunne flytte denne del over på
> >klienten - nemlig ved at have en fortolker på denne - feltet er for dit pro-
> >gram først interessant når det er udfyldt [i de fleste tilfælde], så løsningen
> >ville være:
> >
> > 1) forespørg om klienten tilbyder password-felt
> > 2) hvis ikke - så upload en java/python stump til at løse dette
>
> NC'er er en uddød race. Selv SUN laver SunRay terminaler i stedet (og
> de er endnu mere lowlevel - der kører X-serveren på host-maskinen.

Jeg snakker ikke client-server programmer på NC måden - kun at du lægger en
del af den grafiske abstraktion over på serveren [terminalen] - du vil stadigt
kunne køre standard X - du vil stadigt skulle køre programmet remote.

I øvrigt tror jeg ikke NC'en er død - den er bare i hi [som den har været
før].

Btw. Ved du i øvrigt hvornår man første gang udråbte programmørerne som en
uddøende race? Da den første Fortran compiler kom - nu kunne alle jo selv
lave programmerne!

>
> > 3) bed klienten om at lave et password-felt på (100,200) m. 30 chars
> > [du modtager et windowid - som du så kan forespørge eller modtage
> > mere generelle events fra]
> >
> >princippet er det samme som thin clients - ikke?
> >
> >Og du burde kunne indlægge dette som extention til X.
>
> Ved nærmere eftertanke - er det ikke det Display Postscript gør?
> Programmeringssproget er godt nok et andet...

Ikke helt ved siden af - du kunne gøre begge de 2 ovenstående på DPS [fik
ham ghostscript gutten egentlig nogensinde det til at virke - hmmm - det
må jeg vist hellere kigge på ]

--
Mvh. Kim Petersen /| Tlf: +4575831551 |\ Jomfru Ingefreds Vej 18
Software Engineer / | Fax: (none atm.) | \ 7100 Vejle
LSS / | Email: kim@vindinggaard.dk | \ DK - Danmark

---

Den 29 Nov 2001 20:25:43 +0100 skrev Kim Petersen:
>
>Btw. Ved du i øvrigt hvornår man første gang udråbte programmørerne som en
>uddøende race? Da den første Fortran compiler kom - nu kunne alle jo selv
>lave programmerne!

Nu kender jeg ikke så meget til Fortran, men jeg har set et par Cobol-
programmer, og de er eddermame ikke for programmører.

>> > 3) bed klienten om at lave et password-felt på (100,200) m. 30 chars
>> > [du modtager et windowid - som du så kan forespørge eller modtage
>> > mere generelle events fra]
>> >
>> >princippet er det samme som thin clients - ikke?
>> >
>> >Og du burde kunne indlægge dette som extention til X.
>>
>> Ved nærmere eftertanke - er det ikke det Display Postscript gør?
>> Programmeringssproget er godt nok et andet...
>
>Ikke helt ved siden af - du kunne gøre begge de 2 ovenstående på DPS

Så tror jeg endelig jeg fattede ideen...

>[fik
>ham ghostscript gutten egentlig nogensinde det til at virke - hmmm - det
>må jeg vist hellere kigge på ]

Jeg ved det ikke - jeg så det nævnt engang, og postscript er sg* meget
nemmere at programmere end Xlib, så det kunne da være interessant...

Mvh
Kent
--
Dryp - dryp - dryp <Pfzt>
Keyboard error

---

kfr@fleggaard.dk (Kent Friis) writes:


> NC'er er en uddød race. Selv SUN laver SunRay terminaler i stedet (og
> de er endnu mere lowlevel - der kører X-serveren på host-maskinen.

Det lyder til gengaeld som en god ide, og så med en passende - HURTIG
- protokol til at synkronisere klienten. Er det som i VNC?

--
Thorbjørn Ravn Andersen
http://unixsnedkeren.dk

---

Den 01 Dec 2001 10:35:56 +0100 skrev Thorbjoern Ravn Andersen:
>kfr@fleggaard.dk (Kent Friis) writes:
>
>
>> NC'er er en uddød race. Selv SUN laver SunRay terminaler i stedet (og
>> de er endnu mere lowlevel - der kører X-serveren på host-maskinen.
>
>Det lyder til gengaeld som en god ide, og så med en passende - HURTIG
>- protokol til at synkronisere klienten. Er det som i VNC?

Mit umiddelbare indtryk er at det minder om VNC - incl. at man kan
flytte hele skærmbilledet med åbne programmer fra en skærm til en
anden.

Det skal dog lige siges, at det tætteste jeg har været på en SunRay er
~2 minutter på Cebit, imens en sælger stod og forklarede om det på
vola^H^H^H^Htysk.

Mvh
Kent
--
http://www.celebrityshine.com/~kfr/

---

Kim Petersen <kim@vindinggaard.dk> writes:

> Yip - men det er jo det du gør under alle omstændigheder i X... Det som jeg
> snakkede om - var at du lagde muligheder for højere niveau grafiske elementer
> over på terminalen - eg du definerer en firkant til input til at være tegnet
> på en bestemt måde - du definerer font for feltet - og sender data til det -
> nu skal X når den opdaterer feltet *ikke* forespørge programmet.

Det var lige præcis tanken bag NeWS systemet fra Sun, hvor der var
PostScript i klienten. De ville bare have penge for det, og så gik X
hen og blev standarden (det var Open Source).

Tanken er skam tænkt. Det var bare ikke det folk ville have.

--
Thorbjørn Ravn Andersen
http://unixsnedkeren.dk

---

Thorbjoern Ravn Andersen <thunderbear@bigfoot.com> writes:

> Kim Petersen <kim@vindinggaard.dk> writes:
>
> > Yip - men det er jo det du gør under alle omstændigheder i X... Det som jeg
> > snakkede om - var at du lagde muligheder for højere niveau grafiske elementer
> > over på terminalen - eg du definerer en firkant til input til at være tegnet
> > på en bestemt måde - du definerer font for feltet - og sender data til det -
> > nu skal X når den opdaterer feltet *ikke* forespørge programmet.
>
> Det var lige præcis tanken bag NeWS systemet fra Sun, hvor der var
> PostScript i klienten. De ville bare have penge for det, og så gik X
> hen og blev standarden (det var Open Source).

Jeg tror du glemmer at DPS/X eksisterer (Display Postscript) som kører som
extention på X.

>
> Tanken er skam tænkt.

Det var jeg såmen godt klar over, tanken "surfacer" med mellemrum.

> Det var bare ikke det folk ville have.

Det synes jeg nok er en lidt for hurtig konklusion, såvidt jeg kan se, er der
DPS/X extention på alle de kommercielle X implementeringer, så det vi mangler
er at OpenSource versionen kommer op til spec. Så kan du få lov at erklære den
død, når det viser sig at ingen vil bruge den - ikke?

Se følgende sites for GnuStep og DPS:

http://www.gnustep.org/developers/DGS.html
http://dps.sourceforge.net/

Det ser ud som om der stadigt er liv i projektet, inkluderende nogle Gtk
extentions til at udnytte det.

--
Mvh. Kim Petersen /| Tlf: +4575831551 |\ Jomfru Ingefreds Vej 18
Software Engineer / | Fax: (none atm.) | \ 7100 Vejle
LSS / | Email: kim@vindinggaard.dk | \ DK - Danmark

---

Kim Petersen <kim@vindinggaard.dk> writes:


> Jeg tror du glemmer at DPS/X eksisterer (Display Postscript) som kører som
> extention på X.

Det er meget yngre end NeWS. Bortset fra det, er netop det at det er
en udvidelse af X (og derfor ikke kan garanteres altid at vaere der)
en vigtig faktor, som betyder at kun de faerreste programmer i praksis
benytter det.

Men hvis det betyder at det den oprindelige forespørger gerne ville
have, er muligt af denne vej, så er der jo ikke så meget mere at
gruble over. At implementere.

> > Det var bare ikke det folk ville have.
>
> Det synes jeg nok er en lidt for hurtig konklusion, såvidt jeg kan se, er der
> DPS/X extention på alle de kommercielle X implementeringer, så det vi mangler
> er at OpenSource versionen kommer op til spec. Så kan du få lov at erklære den
> død, når det viser sig at ingen vil bruge den - ikke?

Så vil jeg foreslå dig at du spanker de førende Linuxdistributører til
at få deres X til at inkludere DPS. Som det er i dag, er det noget
som kun et fåtal har adgang til. Og så kan det være nok så smart,
hvis det ikke er noget der bliver brugt af mange.

> Se følgende sites for GnuStep og DPS:
>
> http://www.gnustep.org/developers/DGS.html
> http://dps.sourceforge.net/
>
> Det ser ud som om der stadigt er liv i projektet, inkluderende nogle Gtk
> extentions til at udnytte det.

Ikke vejen frem. Linuxdistributørene skal bruge det - så kommer der
skub i tingene...


--
Thorbjørn Ravn Andersen
http://unixsnedkeren.dk

---

Claus Rasmussen <clr@cc-consult.dk> writes:

> >> Gnome kender jeg ikke, men KDE /er/ langsomt. Det skyldes (i
> >> sammenligningen med Windows) X .............................
> > ^
> > Hvorfor mener du det?
>
> Fordi der er et ekstra lag som alle tegne-kommandoer skal igennem.

Det ekstra lag i forhold til Windows består af serialisering og
deserialisering af ganske få parametre plus kontekstskift mellem
klient og server. Kontekstskift er ret sjældne, for kommunikationen
forgår via en buffer.

Der er ikke nogen tvivl om det er en smule langsommere end GDI i
Windows-kernen. Spørgsmålet er om det er *grunden* til at Gnome og KDE
er langsommere end Windows, altså om det i virkeligheden er noget
andet end X der er flaskehalsen.

Jeg har ikke set nogen målinger som viser at man kan opnå væsentligt
forbedret framerate ved at flytte grafikdriverne tættere på
applikationen. Hvis du har kendskab til nogle, vil jeg gerne se dem.

> Det er et af argumenterne for at basere sig på frame-buffer grafik
> i stedet.

Hvad mener du med framebuffer-grafik? At applikationen selv plotter de
enkelte pixels ind i framebufferen? Det ville være katastrofalt
langsomt.

> Det er en almindelig mening, at X protokollen placerer sig mellem

Den almindelige mening er ikke baseret på målinger.

> to stole: Den er for high-level som desktop (du kan ikke få fat i
> hardwaren men skal altid igennem X's abstraktionslag)

Man kan ikke undgå en eller anden form for abstraktionslag. hvordan
skulle man ellers kunne skrive programmer som virker med mere end ét
grafikkort?

Så spørgsmålet er kun hvor abstraktionslaget skal ligge.

(a) Kernen indeholder grafikdrivere og tilbyder grafik-API.

(b) Grafikdrivere findes i en separat proces, som kun
kortvarigt kræver superbrugeradgang.

I tilfælde (a) kan en fejlagtig grafikdriver bringe hele systemet
ned. I tilfælde (b) kan den kun bringe X-serveren ned, og der ikke
nogen risiko for angreb ved at udnytte fejl i grafikdriverne.

Argumentet for (a) er hastighed, men det er tvivlsomt hvor gyldigt det
argument egentlig er. Det kan meget vel tænkes at flaskehalsene i
virkeligheden ligger i Gtk+ og QT, ikke i X.

---

Soeren Sandmann wrote:

> Claus Rasmussen <clr@cc-consult.dk> writes:
>
>> >> Gnome kender jeg ikke, men KDE /er/ langsomt. Det skyldes (i
>> >> sammenligningen med Windows) X .............................
>> > ^
>> > Hvorfor mener du det?
>>
>> Fordi der er et ekstra lag som alle tegne-kommandoer skal igennem.
>
> Det ekstra lag i forhold til Windows består af serialisering og
> deserialisering af ganske få parametre plus kontekstskift mellem
> klient og server. Kontekstskift er ret sjældne, for kommunikationen
> forgår via en buffer.

Arhj, jeg vil ikke kalde dem "sjældne"... Mindst eet kontekst skift
pr. opdatering af skærmen. Og med de grafik-intensive applikationer som
findes i Gnome og KDE vil bufferen hurtigt løbe over, og så taler vi
snarere om /mange/ kontekstskift hver gang et vindue skal tegnes.


> Der er ikke nogen tvivl om det er en smule langsommere end GDI i
> Windows-kernen. Spørgsmålet er om det er *grunden* til at Gnome og KDE
> er langsommere end Windows, altså om det i virkeligheden er noget
> andet end X der er flaskehalsen.

Jeg skrev et længere indlæg for nogen tid siden om nøjagtigt det samme
spørgsmål. Jeg konkluderede dengang, at den dårlige performance i X (læs:
KDE/Gnome) skyldtes den akkumulerede effekt af en række dårligdomme i
X, KDE, kernen og gcc.

Det var den korte version, jeg kom med i denne omgang

Jeg er enig med dig i, at X nok ikke er den største synder, men mener
at X alligevel bidrager til den dårlige performance. Dermed ikke sagt,
at man ikke får noget til gengæld for den lidt dårligere performance.
Der er features i X, som ville være svært at undvære - også selv om
de koster lidt på performance.


> Jeg har ikke set nogen målinger som viser at man kan opnå væsentligt
> forbedret framerate ved at flytte grafikdriverne tættere på
> applikationen. Hvis du har kendskab til nogle, vil jeg gerne se dem.

Jeg har hørt meldinger om, at frame-buffer kører hammer hurtigt i
sammenligningen med X.

[...]

>> Det er en almindelig mening, at X protokollen placerer sig mellem
>> to stole: .......................................................
>
> Den almindelige mening er ikke baseret på målinger.

Man kan ikke måle på forskellige design-beslutninger. Kun på forskellige
implementationer af designet. For at kunne måle om X protokollen er
designet rigtigt skulle du først skrive en "Y" server med en alternativ
protokol og evt. en protokol uden network-transparency. Det ville jo
være som at sammenligne pærer og bananer.


>> ......... Den er for high-level som desktop (du kan ikke få fat i
>> hardwaren men skal altid igennem X's abstraktionslag)
>
> Man kan ikke undgå en eller anden form for abstraktionslag. hvordan
> skulle man ellers kunne skrive programmer som virker med mere end ét
> grafikkort?

Nej naturligvis ikke. Men når jeg skriver, at X er for high-level, mener
jeg, at du ikke fra applikationen (desktop environmentet) kan få fat i
de primitive tegne-operationer.

Altså: Under X mapper du først fra den tegne-operation, du ønsker at
udføre til den tilsvarende kommando i X. X mapper derefter denne kom-
mando over i en abstrakt tegneoperation som sendes videre til det lag,
der abstraherer over grafikkort (driver-laget).

I frame-buffer grafik (og Windows) springer du et lag over.


> Så spørgsmålet er kun hvor abstraktionslaget skal ligge.
>
> (a) Kernen indeholder grafikdrivere og tilbyder grafik-API.
>
> (b) Grafikdrivere findes i en separat proces, som kun
> kortvarigt kræver superbrugeradgang.
>
> I tilfælde (a) kan en fejlagtig grafikdriver bringe hele systemet
> ned. I tilfælde (b) kan den kun bringe X-serveren ned, og der ikke
> nogen risiko for angreb ved at udnytte fejl i grafikdriverne.

Det er een af de features som X giver til gengæld for dårligere performance.
Det er et trade-off. Det er givet et fornuftigt valg, der er blevet
truffet, men det bidrager altså stadig til den dårlige performance.


> Argumentet for (a) er hastighed, men det er tvivlsomt hvor gyldigt det
> argument egentlig er. Det kan meget vel tænkes at flaskehalsene i
> virkeligheden ligger i Gtk+ og QT, ikke i X.

Som et eksempel på effekten af at flytte funktioner ind i kernen, kan
du tage web-serverne Tux og Apache. Tux er verdensrekordholder for web-
servere !

Forstå mig ret: Jeg argumenterer ikke for, at /alt/ skal flyttes ind i
kernen. Jeg påpeger bare, at vi har faktisk et performance problem, og
at det delvist skyldes designet af X.

-Claus

---

Claus Rasmussen <clr@cc-consult.dk> writes:

> spørgsmål. Jeg konkluderede dengang, at den dårlige performance i X (læs:
> KDE/Gnome) skyldtes den akkumulerede effekt af en række dårligdomme i
> X, KDE, kernen og gcc.

X lider under at være designet af nogen ph.d. studerende, og at være
forholdsvist svært at skrive kode til. Derfor bliver ting som KDE og
Gnome let langsomme alene fordi der skal meget kode til at lave det
ønskede resultat, og at det fylder. Jeg har set ren X-programmering
sammenlignet med at uddrage kvadratrødder med romertal.

Jeg har Mandrake 8.1 kørende på to maskiner, hvor den ene er ny og den
anden er ~4 år gammel med sløve diske og kun 64 Mb ram. Det kører
fint på den nye, men hoster gevaldigt på den gamle. Det skal man også
tage hensyn til. Og hvis man kører både gnome og kde ting samtidig
skal det næsten gå galt.


> Det er een af de features som X giver til gengæld for dårligere performance.
> Det er et trade-off. Det er givet et fornuftigt valg, der er blevet
> truffet, men det bidrager altså stadig til den dårlige performance.

Det bliver spændende når der kommer en X driver til en
Linuxkernedrevet framebuffer. Det skulle vel give optimal ydelse.

> Som et eksempel på effekten af at flytte funktioner ind i kernen, kan
> du tage web-serverne Tux og Apache. Tux er verdensrekordholder for web-
> servere !

Apache kan også en million ting som Tux ikke kan. Det tager altså tid
at skulle checke 100.000 forskellige ting på vejen ud.

> Forstå mig ret: Jeg argumenterer ikke for, at /alt/ skal flyttes ind i
> kernen. Jeg påpeger bare, at vi har faktisk et performance problem, og
> at det delvist skyldes designet af X.

Enig. Hvad skal der gøres ved det? Der findes projekter som Berlin.

Ulempen er - som altid - bagudkompataibilitet.
--
Thorbjørn Ravn Andersen
http://unixsnedkeren.dk

---

Thorbjoern Ravn Andersen wrote:

> Claus Rasmussen <clr@cc-consult.dk> writes:

> X lider under at være designet af nogen ph.d. studerende, og at være
> forholdsvist svært at skrive kode til. Derfor bliver ting som KDE og
> Gnome let langsomme alene fordi der skal meget kode til at lave det
> ønskede resultat, og at det fylder. Jeg har set ren X-programmering
> sammenlignet med at uddrage kvadratrødder med romertal.

LOL !!

[...]

>> Som et eksempel på effekten af at flytte funktioner ind i kernen, kan
>> du tage web-serverne Tux og Apache. Tux er verdensrekordholder for web-
>> servere !
>
> Apache kan også en million ting som Tux ikke kan. Det tager altså tid
> at skulle checke 100.000 forskellige ting på vejen ud.

Ja, og X har network-transparency. Ideen med sammenligningen var, at hvis
vi pillede ved designet (altså skrottede network-tranparency) og flyttede
X ind i kernen ville vi kunne få en performance gevinst - som et argument
i mod at det ikke betød noget, om serveren lå i kernen eller ej.

Men ellers er vi enige.

-Claus

---

Claus Rasmussen <clr@cc-consult.dk> writes:

> Ja, og X har network-transparency. Ideen med sammenligningen var, at hvis
> vi pillede ved designet (altså skrottede network-tranparency) og flyttede

Det er slet ikke nok. Selve den grundlæggende model med den maade X
fungerer paa skal laves om for at gevinsten kommer. Og der er stadig
problemet med at der skal stor, tung kode til at faa det oenskede
resultat. Det sloever i sig selv.

Se fx paa de X-optimeringsting der findes som lbxproxy, mv.
--
Thorbjørn Ravn Andersen
http://unixsnedkeren.dk

---

Den 28 Nov 2001 12:08:27 +0100 skrev Thorbjoern Ravn Andersen:
>Claus Rasmussen <clr@cc-consult.dk> writes:
>
>> Det er een af de features som X giver til gengæld for dårligere performance.
>> Det er et trade-off. Det er givet et fornuftigt valg, der er blevet
>> truffet, men det bidrager altså stadig til den dårlige performance.
>
>Det bliver spændende når der kommer en X driver til en
>Linuxkernedrevet framebuffer. Det skulle vel give optimal ydelse.

Der findes allerede en Frame-buffer X-server. Det anbefales ikke at
bruge den, hvis man har et grafikkort der er direkte understøttet,
fordi det går meget hurtigere hvis X-serveren kan snakke direkte med
grafikkortet.

Selvfølgelig, hvis du mener en XLib der snakker direkte med frame-
bufferen, sparer du et lag. Men til gengæld har du stadig problemet
med at normale programmer regner i firkanter, linier og bitmaps[1],
men framebufferen regner i pixels.

Det absolut hurtigste ville selvfølgelig være en XLib skrevet specielt
til hvert eneste grafikkort, men så vil jeg blot ønske god fornøjelse,
og håbe på at du har en preview klar, når Linux 8.5.137 bliver
frigivet

Mvh
Kent

[1] Eller trekanter og vertex'es, hvis vi snakker Quake.
--
Dryp - dryp - dryp <Pfzt>
Keyboard error

---

Claus Rasmussen wrote:

>

>>Argumentet for (a) er hastighed, men det er tvivlsomt hvor gyldigt det
>>argument egentlig er. Det kan meget vel tænkes at flaskehalsene i
>>virkeligheden ligger i Gtk+ og QT, ikke i X.
>
> Som et eksempel på effekten af at flytte funktioner ind i kernen, kan
> du tage web-serverne Tux og Apache. Tux er verdensrekordholder for web-
> servere !
>
> Forstå mig ret: Jeg argumenterer ikke for, at /alt/ skal flyttes ind i
> kernen. Jeg påpeger bare, at vi har faktisk et performance problem, og

> at det delvist skyldes designet af X.

Det er ikke helt rigtigt - der er faktisk lavet en webserver der kører i
"user-space" og lige så hurtig. Dette er så også kun den halve
sandhed, da en del stor del af TUX (hvis jeg forstår det korrekt), blot
udnytter nogle af de nye features i 2.4 kernen. Læs f.eks. denne post
fra Ingo Molnar, personen bag Tux:
http://www.uwsg.indiana.edu/hypermail/linux/kernel/0104.3/0814.html


--
Joergen Ramskov - Folding for the Cause!
http://teameggroll.com

---

Claus Rasmussen <clr@cc-consult.dk> writes:

> Man kan ikke måle på forskellige design-beslutninger. Kun på forskellige
> implementationer af designet. For at kunne måle om X protokollen er
> designet rigtigt skulle du først skrive en "Y" server med en alternativ
> protokol og evt. en protokol uden network-transparency. Det ville jo
> være som at sammenligne pærer og bananer.

Man kan sagtens måle hvor meget af tiden mellem to frames der går

- i applikationen (Gtk+/QT, XLib (og vistnok Xt i QT's
tilfælde)),

- i X-serveren ved forskellige grafikkort med varierende
grader af accelerering.

- i kernen.

- i windowmanageren

Det er besværligt at gøre, men ikke umuligt. Sådan nogle tal vil
fortælle præcist *hvor meget* man betaler for at have et
client/server-design.

Hvis det ekstra tidsforbrug pr. frame er fx 1%, vil man ikke vinde
noget af betydning ved at flytte grafikdriverne tættere på
applikationen. I det tilfækde er det toolkittet eller XLib der skal
forbedres.

Hvis det ekstra tidsforbrug er 95%, er det ikke applikationen der skal
forbedres, men nærmere kernen, X-serveren eller windowmanageren, og
løsningen kan meget vel være at integrere delene tættere.

Pointen er at uden sådanne målinger er en påstand som "X er skyld i at
Gnome og KDE er langsomme" ikke konstruktiv. Man risikerer at fjerne
fokus fra de områder hvor problemerne er, og i stedet spilde tiden på
at "forbedre" noget som allerede virker glimrende.

> Det er een af de features som X giver til gengæld for dårligere
> performance. Det er et trade-off. Det er givet et fornuftigt valg,
> der er blevet truffet, men det bidrager altså stadig til den dårlige
> performance.

Ja, men bidrager det noget af betydning? Måske, måske ikke.

---

Soeren Sandmann wrote:

> Pointen er at uden sådanne målinger er en påstand som "X er skyld i at
> Gnome og KDE er langsomme" ikke konstruktiv. Man risikerer at fjerne
> fokus fra de områder hvor problemerne er, og i stedet spilde tiden på
> at "forbedre" noget som allerede virker glimrende.

Uden i øvrigt at ville modsige dit glimrende skriv, så har det altså
aldrig været påstanden at "X er skyld i at Gnome og KDE er langsomme".

Påstanden har hele tiden været, at "X er en /bidragyder/ til den dårlige
performance".

At det så har virket som flame-bait på en hel del, da de måske har
læst det som, at "Windows er meget bedre" eller at "klient/server er
noget møg" er så en anden sag. Men jeg mener, at vi undervejs i diskus-
sionen er kommet vidt omkring i X verdenen og at der er kommet en "bredere"
forståelse for, at der er ting i X, som nok kunne være gjort bedre.

-Claus

---

Soeren Sandmann wrote:

>
> Så spørgsmålet er kun hvor abstraktionslaget skal ligge.
>
> (a) Kernen indeholder grafikdrivere og tilbyder grafik-API.
>
> (b) Grafikdrivere findes i en separat proces, som kun
> kortvarigt kræver superbrugeradgang.
>
> I tilfælde (a) kan en fejlagtig grafikdriver bringe hele systemet
> ned. I tilfælde (b) kan den kun bringe X-serveren ned, og der ikke
> nogen risiko for angreb ved at udnytte fejl i grafikdriverne.
>
> Argumentet for (a) er hastighed, men det er tvivlsomt hvor gyldigt det
> argument egentlig er. Det kan meget vel tænkes at flaskehalsene i
> virkeligheden ligger i Gtk+ og QT, ikke i X.

Først vil jeg lige sige at absolut ikke er nogen ekspert på området - tværtimod!


Jeg vil derimod blot henvise til at Waldo Bastian (en KDE udvikler) har
lavet en analyse:

http://dot.kde.org/989353453/



--
Joergen Ramskov - Folding for the Cause!
http://teameggroll.com

---

"Lars Overgaard" <lars@linuxnet.dk> writes:

> Er jeg den eneste, der sidder med indtrykket af, at KDE2 er genial...men
> langsom? Jeg bruger RH 7.2 på følgende hardware:
[snip]

> Jeg dualbooter med Win2K, som kører helt forrygende. Ingen problemer med
> hastigheden overhovedet.
>
> Det er også galt under RH 7.1 og Mandrake.
>
> Er det generelt at KDE (og Gnome for den sags skyld) kører langsomt, eller er
> det bare min hardware, der ikke er Linux-venligt?

Personligt synes jeg at KDE køre væsentligt langsommere på Mandrake end
på min RH7.2

---

"Lars Overgaard" <lars@linuxnet.dk> wrote in message
news:48fbb8d93a5d1b3cc2f8011ff62c24bd.46160@mygate.mailgate.org...
> Er jeg den eneste, der sidder med indtrykket af, at KDE2 er genial...men
> langsom?

Jeg har haft spørgsmålet op og vende engang før på denne NG... prøv at rode
til bage i nogle gamle indlæg (er det en måned siden?) der var nogle gode
kvalificerede svar.
Men det ER rigtig. X/KDE er ikke voldsom hurtig. Ikke i forhold til en
win2k.

---

Lars Overgaard wrote:

> Er jeg den eneste, der sidder med indtrykket af, at KDE2 er
> genial...men langsom? Jeg bruger RH 7.2 på følgende hardware:
>
> Epox MVP3-C2
> AMD K6-2 500
> 256 MB ram
> 9.1 GB IBM HD (7200 rpm / 2 MB)
> Riva TNT2 32 MB
<snip>

Jeg kører SuSE 7.2 på næsten samme konfiguration, bare med 512
MB RAM, et ATI Rage Fury, en langsommere harddisk og et MVP3-G5.

Jeg ved godt hvad du mener, men har du prøvet med KDE 2.2.2 ?
Den gav et glimrende tilskud til farten her, et der endda også
kunne mærkes på min Duron 700 ...

--
MVH
Thomas A. Frederiksen
Registered Linux user #168164, http://counter.li.org