WWW-läsare.
Kimmo Björnsson
ibrowse (ibrowse också förresten) Juggler tex..
/ Kimmo .......
Jonas Elfström
Jag ligger på Juggler mailinglistan och den är långt ifrån färdig.
Ibrowse ligger på http://www.omnipresence.com och är version 0.48,
enormt buggig och långt kvar där också men som sagt det är ju bara 0.48
och bättre att man får se någonting iaf!
Kolla också in http://www.cucug.org/amiga.html under "news" så stod det
något om ännu en browser, minns inte riktigt vad.
Enligt min åsikt så är det bara ALynx som går att använda än så länge och
den borde också utvecklas en hel del till...
Synd och skam att Amigan inte har någon vettig browser!
--
/ Jonas Elfstrom (5+ rows .sigs sux) ecs...@klecsd.ericsson.se \
< Amiga, Linux, ISP, C, 680x0/6502 ASM. Beer. Suede, DM, SoM, U2. >
\ Everything written above is my point of view not Ericsson's /
Jan Karjalainen
>ibrowse (ibrowse också förresten) Juggler tex..
>/ Kimmo .......
Det finns en webläsare, Voyager, som har nått alpha-status.
Skriven av Oliver Wagner, mannen bakom AmIRC och AmFTP.
Kimmo Björnsson
>>ibrowse (ibrowse också förresten) Juggler tex..
>Det finns en webläsare, Voyager, som har nått alpha-status.
>Skriven av Oliver Wagner, mannen bakom AmIRC och AmFTP.
Var kan man få tag på info om den?
/ Kimmo .......
Janne Johansson
JK> > än ibrowse (ibrowse också förresten) Juggler tex..
JK>
JK> Det finns en webläsare, Voyager, som har nått alpha-status.
JK> Skriven av Oliver Wagner, mannen bakom AmIRC och AmFTP.
Finns var? Finns öht?
/Janne Johansson
*FSED91m*
Oskar Sundberg
>>>Någon som vet hur det går med utvecklingen av de andra webläsarna än
>>>ibrowse (ibrowse också förresten) Juggler tex..
>>>/ Kimmo .......
>>Det finns en webläsare, Voyager, som har nått alpha-status.
>>Skriven av Oliver Wagner, mannen bakom AmIRC och AmFTP.
>Jahadu... Har du hört någe om Juggler & Voyager ???
>Säg till om du hittar nånstans
http://wade1.ab.umd.edu/support/voyager - kan du ju prova om du vill. :)
--
Oskar Gary Sundberg / ga...@canit.se / P-Gary / http://www.canit.se/~gary
ToH, MusiHlp & WebGfx development / Please don't pull my string, girl...
Thom Eichhorn
Jan Karjalainen
>>>ibrowse (ibrowse också förresten) Juggler tex..
>>>/ Kimmo .......
>>Det finns en webläsare, Voyager, som har nått alpha-status.
>>Skriven av Oliver Wagner, mannen bakom AmIRC och AmFTP.
>Är den bra, och var finns den (är den gratis??)????
Voyager kommer att bli shareware (det var det jag hörde), och det jag har sett
av den är bra. Den finns inte tillgänglig till allmänheten än, nuvarande
version är 0.19alpha. Den stöder inte forms än, eller inline pics.
MUI3.1 är ett krav.
Den har 8-10 "sockets" i alpha-versionen (se IBrowse...).
Så mycket mer vet jag inte, förrän nästa alpha, eller beta version kommer,
förhoppningsvis med forms och inline pics support. Backgrounds ska visst också
komma snart...
-> Jan Karjalainen <-
Tomas Carlsson
Mattias Karlsson
> MUI3.1 är ett krav.
Vad är det med MUI som gör att var och varenda browser måste använda det?
Ex.job Z/ETC Per Salmi Z/EG
>
>> MUI3.1 är ett krav.
>
>Vad är det med MUI som gör att var och varenda browser måste använda det?
Det är väldigt enkelt och smidigt att ordna avancerade grafiska gränssnitt
med MUI. Man får väldigt mycket gratis så att säga...
--
Per Salmi
Daniel Adolfsson
>Peter Magnusson (io...@augs.se) wrote:
>>>> MUI3.1 är ett krav.
>>>Vad är det med MUI som gör att var och varenda browser måste använda det?
>>Amigans WWW browser ska vara lika slött som PC:s WWW browsers? ;)
>MUI är ju ursnabbt! MCP's Full-Window-Move och Full-Window-Size rejsar på som
>om den aldrig gjort något annat. :)
NEEEJ! Det är bara MCP Config-program som är ett "MUI-GUI". Själva MCP har
inget med MUI att göra. Det är därför det är snabbt! (och väldigt snabbt på
ditt CS060/CV64...)
--
/Daniel
_/ Systemfriendly programmer | Amiga - Back for the Future! | IRC: \_
/ [amigaE^asm^ced^fetchrefs] | » PGP Public key available « | Sensei \
Stefan Burstrom
>I en artikel skrev Daniel Nyberg <dan...@dalnet.se>:
>>Peter Magnusson (io...@augs.se) wrote:
>>>>> MUI3.1 är ett krav.
>>>>Vad är det med MUI som gör att var och varenda browser måste använda det?
>>>Amigans WWW browser ska vara lika slött som PC:s WWW browsers? ;)
>>MUI är ju ursnabbt! MCP's Full-Window-Move och Full-Window-Size rejsar på
>>som om den aldrig gjort något annat. :)
>NEEEJ! Det är bara MCP Config-program som är ett "MUI-GUI". Själva MCP har
>inget med MUI att göra. Det är därför det är snabbt! (och väldigt snabbt på
>ditt CS060/CV64...)
JOODÅ! :-)
FullWindowMove och FullWindowResize! Gissa vad dom två funtionerna gör!
Att säga att någonting är snabbt beroende på att det inte använder MUI är
lika löjligt att tro att IBrowse skulle bli mycket snabbare utan MUI.
90-95% av all tid i IBrowse spenderas i min kod, jpeg/gif decoders etc.
så även om jag inte använde MUI så skulle IBrowse inte bli mere än
5-10% snabbare (förutsatt att det fans ett gui system som tog 0% CPU tid)
Om man ser till vad MUI gör så skulle man inte säga att MUI är slött.
Jag känner Stefan Stuntz ganska väl och jag kan säga att han är en av dom
bättre programmerarna jag mött, så att säga att MUI är dåligt programmerat
är bara en dålig gissning)
btw, Daniel Nyberg:
Vilken version av MCP har du? Min buggar som bara den. (Jag undrar om det
beror på MUI? Jag menar, "Själva MCP har inget med MUI att göra" och ändå
buggar det :-)
regards, Stefan Burstroem
° ° _!_ ° o °
o ° O | ° ° o ° °
>> Irl: Stefan Burstroem << °>> Omnipresence Intl. << >> Irc: Yabba <<
>> Phone/Fax: +46 (0)40 - 44 12 27 << >> EMail: f94...@efd.lth.se <<
° ° o O _!_ ° ° _!_ ° °
° ° ° | ° ° o ° | ° ° o
Mikael Berglund
>MUI är betydligt mycket bättre sedan 3.0, eftersom det var mycket
>långsammare förut så måste han trots sin oerhörda skicklighet
>ha missat en hel del.
Han har säkert inte missat så mycket utan MUI:s design styr hur man måste
lösa det. Han har kanske kommit så långt i utvecklingen att han kan göra
vissa optimeringar av designen utan att måla in sig i ett hörn. MUI är
fruktansvärt komplext (om det nu undgått någon :D). Dessutom så exekveras
ett MUI-GUI på progammets context, vilket har en del fördelar gentemot att
exekvera på Intuitions context, och har du då låg prioritet på programmet
kommer det att ta lång tid på sig. Man skulle kunna lösa det genom att ha en
högprioritetsprocess som är ansvarig för just GUI-delen så att när displayen
skall uppdateras så får den processen den tid den behöver. Jag är inte säker
på att Amigans system lämpar sig för MUI:s lösning ur hastighetssynpunkt.
Själv skyr jag MUI pga dess långsamhet och använder endast MUI-applikationer
där inget alternativ finns. Dock så jag gillar idén med customiserade GUI:n.
--
Regards TMB PGP public key available
Stefan Burstrom
>Han har säkert inte missat så mycket utan MUI:s design styr hur man måste
>lösa det. Han har kanske kommit så långt i utvecklingen att han kan göra
>vissa optimeringar av designen utan att måla in sig i ett hörn. MUI är
>fruktansvärt komplext (om det nu undgått någon :D). Dessutom så exekveras
Tyvär så finns det inte så många sätt att implementera MUI på när man
använder BOOPSI.
>ett MUI-GUI på progammets context, vilket har en del fördelar gentemot att
>exekvera på Intuitions context, och har du då låg prioritet på programmet
>kommer det att ta lång tid på sig. Man skulle kunna lösa det genom att ha en
Det tar inte märkvärt längre tid. De enda gångerna det gör det är då man
har andra taskar 'Running'
BTW, Titta på ett normalt gadtools program. Även om knappar 'trycks in'
snabbare än I mui så reagerar programmet inte snabbare. Skall man dessutom
resiza fönster så måste mycket kod exekveras på applikationens context och
då får du exact samma resultat som i MUI.
Mikael Berglund
SB> Tyvär så finns det inte så många sätt att implementera MUI på när man
SB> använder BOOPSI.
Tja, alla klasser är byggda på Intuitions rootclass och sedan sköter MUI
allt själv för att inte vara lika begränsat som Intuitions BOOPSI-system.
Detta gör att MUI kör sitt eget race bredvid Intuitions och delvis kopierar
dess funktion gentemot klienterna som använder MUI. Fördelen är att Stefan
kan bygga upp MUI som han vill utan att begränsa sig. Nackdelen är att han
får göra mycket av Intuitions arbete själv samt att han inte kan nyttja
Intuitions fördelar.
SB> Det tar inte märkvärt längre tid. De enda gångerna det gör det är då man
SB> har andra taskar 'Running'
För mig gör det det. Dessutom så uppdateras inte displayen om programmet
råkar vänta på något annat och inte hanterar MUI:s meddelande. Fruktansvärt
irriterande. Som sagt är inte programmet låst tar det inte mycket mer tid än
för Intuition men dock märkbart men vissa saker kan Intuition göra TROTS att
programmet som äger displayen väntar på ett annat event.
SB> BTW, Titta på ett normalt gadtools program. Även om knappar 'trycks in'
SB> snabbare än I mui så reagerar programmet inte snabbare.
Hur mäter du det? Genom att test på 'känsla' på en maskin av typ...?
SB> Skall man
SB> dessutom resiza fönster så måste mycket kod exekveras på applikationens
SB> context och då får du exact samma resultat som i MUI.
Inte om programmet inte explicit behöver det. Själv kör jag GadOutline som
GUI-engine och de effekter som MUI uppvisar under tung belastning visar sig
inte med GadOutline. Dock så erbjuder ju GO inte samma fina
högnivåfunktioner som MUI. MUI är mer än en GUI-layoutengine.
Stefan Burstrom
>Tja, alla klasser är byggda på Intuitions rootclass och sedan sköter MUI
>allt själv för att inte vara lika begränsat som Intuitions BOOPSI-system.
>Detta gör att MUI kör sitt eget race bredvid Intuitions och delvis kopierar
>dess funktion gentemot klienterna som använder MUI. Fördelen är att Stefan
>kan bygga upp MUI som han vill utan att begränsa sig. Nackdelen är att han
>får göra mycket av Intuitions arbete själv samt att han inte kan nyttja
>Intuitions fördelar.
Faktiskt så görs mycket mer än du tror av intuition. Det enda egentliga som
inte görs av intuition är layout och gadget render vilket nuvarande
intuition ändå inte klarar av.
Btw, MUI använder inte längre rootclass. MUI använder en custom root klass
som använder memory pools och är ca 100% snabbare att skapa.
SB>> Det tar inte märkvärt längre tid. De enda gångerna det gör det är då man
SB>> har andra taskar 'Running'
>För mig gör det det. Dessutom så uppdateras inte displayen om programmet
>råkar vänta på något annat och inte hanterar MUI:s meddelande. Fruktansvärt
>irriterande. Som sagt är inte programmet låst tar det inte mycket mer tid än
>för Intuition men dock märkbart men vissa saker kan Intuition göra TROTS att
>programmet som äger displayen väntar på ett annat event.
SB>> BTW, Titta på ett normalt gadtools program. Även om knappar 'trycks in'
SB>> snabbare än I mui så reagerar programmet inte snabbare.
>Hur mäter du det? Genom att test på 'känsla' på en maskin av typ...?
Genom att jag vet hur programmen funkar:
MUI:
Input event -> MUI -> Render gadget -> Execute funktion
Utan MUI:
Input event -> Render gadget (input.device)
|
\-> Execute funktion (application context)
Det enda i MUI som tar längre tid är att rendrera gadgeten men det är inte
så konstigt eftersom de flesta mui gadgets är mycket mer grafiskt krävande.
>Inte om programmet inte explicit behöver det. Själv kör jag GadOutline som
>GUI-engine och de effekter som MUI uppvisar under tung belastning visar sig
>inte med GadOutline. Dock så erbjuder ju GO inte samma fina
>högnivåfunktioner som MUI. MUI är mer än en GUI-layoutengine.
Nu jämför du äpplen och päron så det du säger saknar relevans.
Ett program måste _alltid_ execverar custom kod om det skall resiza ett
komplexr fönster. Om det görs på input.device context eller på
applikationens context spelar ingen roll för hastigheten. (totalt sett)
Mikael Berglund
SB> Faktiskt så görs mycket mer än du tror av intuition. Det enda egentliga
SB> som inte görs av intuition är layout och gadget render vilket nuvarande
SB> intuition ändå inte klarar av. Btw, MUI använder inte längre rootclass.
SB> MUI använder en custom root klass som använder memory pools och är ca
SB> 100% snabbare att skapa.
Jo, men som sagt mesta delen av arbetet dvs layout och gadget rendering görs
ju utav MUI. Där spenderas mesta delen av tiden. Intuition förmedlar ju bara
det som händer till MUI, men därefter så sköter MUI resten, eller hur?
Applikationerna får inga direkta meddelanden från Intuition vad gäller deras
GUI utan detta kommer via MUI. Allt skall alltså kokas av MUI och det är
inte gratis.
Gadget rendering sköter väl Intuition, hur skulle annars en knapp bli
intryckt om inte Intuition talade om det för objektet (BOOPSI) alternativt
skötte det själv som vanligt?
SB> Genom att jag vet hur programmen funkar:
SB> MUI:
SB> Input event -> MUI -> Render gadget -> Execute funktion
| |
Här skulle jag tippa en del tid går åt också.
SB> Utan MUI:
SB> Input event -> Render gadget (input.device)
SB> |
SB> \-> Execute funktion (application context)
Det gör visserligen inte så att programmet i sig reagerar snabbare men man
undviker det oroliga att sitta och klicka på en knapp 10 ggr. Huvudsaken för
användaren är ju att han SER att knappen reagerade, sedan att programmet tar
lika lång tid på sig att svara är en annan sak. Då har han iaf en visuell
bekräftelse på att något hänt och han accepterar lättare en fördröjning till
resultatet.
Sådana misstag gör jag ENDAST med MUI applikationer (men jag lär mig så
smått :D)
SB> Det enda i MUI som tar längre tid är att rendrera gadgeten men det är
SB> inte så konstigt eftersom de flesta mui gadgets är mycket mer grafiskt
SB> krävande.
Hm, ett par oklarheter. input.device handhar väl inte själva renderingen
eftersom Intuiton ansvarar för detta?
Input event (input.device) -> Render gadget (Intuition)
|
\-> Execute function (application)
Skulle jag vilja ha det till. Men du kanske med parenteserna menar vilken
context som avses trots att du inte skrev ut i alla vilket ger intrycket av
att du avser vem som ansvarar för vad.
En annan sak du inte tagit med är att renderingen sker på processens context
vilket gör att uppdateringen kan gå avsevärt slöare om den har låg
prioritet.
Det finns standard BOOPSI-objekt med mer avancerad grafik än tex GadTools
som inte lider av detta. Nackdelen är att väl att alla MUI-objekt har ett
avancerat standard gränssnitt oavsett om implementeringen som sådan behöver
det, eller hur?
>>Inte om programmet inte explicit behöver det. Själv kör jag GadOutline som
>>GUI-engine och de effekter som MUI uppvisar under tung belastning visar sig
>>inte med GadOutline. Dock så erbjuder ju GO inte samma fina
>>högnivåfunktioner som MUI. MUI är mer än en GUI-layoutengine.
SB> Nu jämför du äpplen och päron så det du säger saknar relevans.
Gör jag? Utåt sett så gör GO/MUI samma sak i detta fallet, de ansvarar för
att fönstret layoutas om efter en resize. Inga av MUI:s fancy funktioner
behövs för detta. Ändå tar det avsevärt längre tid för MUI att prestera
samma sak.
SB> Ett program måste _alltid_ execverar custom kod om det skall resiza ett
SB> komplexr fönster. Om det görs på input.device context eller på
SB> applikationens context spelar ingen roll för hastigheten. (totalt sett)
Så att mina måhända enkla tester av att jämföra avancerade GUI:n av MUI/GO
typ som ger två olika känslor av snabbhet beror på något annat än att det
ena går långsammare än det andra? Trots att det GUI som GO hade innehöll
avsevärt fler gadgets :D
Om programmet som har ansvar för att grafiken uppdateras så har det en viss
betydelse hur fort det programmet får CPU. Om vi tar ett extremfall:
Låt din process ligga på -128 om den nu får ett meddelande om att GUI:et
behöver uppdateras så talar det om att det går alldeles utmärkt eftersom den
inget annat har för sig. Eftersom de objekt som den skapat kommer att
exekveras på den processens context så kommer de också att använda den tid
som de får vilken kan bli väldigt liten vid en prioritet -128.
Däremot om Intuition skickar meddelandet att fönstret resizats och
programmet svarar att det går bra uppdateras ditt fönster snabbare eftersom
Intuiton kör på input.devices context dvs 20 och därmed tar den tid det
behöver ÄVEN om det finns andra processer från 19 ner till -128.
Beroende på hur uppläggningen ser ut så blir det mer eller mindre effekt.
Med context så avses alltså inte bara miljön utan även den prioritet som
processen innehar. Stuntz kanske avser något annat med context, jag vet
inte.
Det är iaf min oexpert förklaring varför MUI beter sig som det gör i vissa
fall. I slutändan, vilket är det som räknas är iaf MUI slöare än något annat
layout library jag sett vilket torde bero på något. Om du anser dig vara
expert på MUI så kanske du kan förklara det.
Dessutom, de tester jag gjort med MUI är ren installation v3 utan fancy
saker. Alla program kör sina defaults.
Stefan Burstrom
>In a message 28-Jan-96 22:06:18 Stefan Burstrom <burs...@df.lth.se> wrote:
>Gadget rendering sköter väl Intuition, hur skulle annars en knapp bli
>intryckt om inte Intuition talade om det för objektet (BOOPSI) alternativt
>skötte det själv som vanligt?
Ja, intuition (läs: input.device) rendrerar alla BOOPSI object som är
subklasser av ImageClass och GadgetClass
SB>> Genom att jag vet hur programmen funkar:
SB>> MUI:
SB>> Input event -> MUI -> Render gadget -> Execute funktion
> | |
> Här skulle jag tippa en del tid går åt också.
Ja, men det är faktiskt inte så farligt mycket tid som går åt här.
SB>> Utan MUI:
SB>> Input event -> Render gadget (input.device)
SB>> |
SB>> \-> Execute funktion (application context)
>Det gör visserligen inte så att programmet i sig reagerar snabbare men man
>undviker det oroliga att sitta och klicka på en knapp 10 ggr. Huvudsaken för
>användaren är ju att han SER att knappen reagerade, sedan att programmet tar
>lika lång tid på sig att svara är en annan sak. Då har han iaf en visuell
>bekräftelse på att något hänt och han accepterar lättare en fördröjning till
>resultatet.
Detta är faktiskt en smaksak. Jag har mött folk som föredrar båda typerna.
(THOR tex kan man trycka sig fördärvad på 'Abort' vilket jag inte gillar.)
>Sådana misstag gör jag ENDAST med MUI applikationer (men jag lär mig så
>smått :D)
SB>> Det enda i MUI som tar längre tid är att rendrera gadgeten men det är
SB>> inte så konstigt eftersom de flesta mui gadgets är mycket mer grafiskt
SB>> krävande.
>Hm, ett par oklarheter. input.device handhar väl inte själva renderingen
>eftersom Intuiton ansvarar för detta?
Nåja, det blev lite begrepsförvirring.
Intuition finns inte som task untan den är beroende av att input.device
talar om vad som händer via funktionen Intuition()
>Input event (input.device) -> Render gadget (Intuition)
> |
> \-> Execute function (application)
>Skulle jag vilja ha det till. Men du kanske med parenteserna menar vilken
>context som avses trots att du inte skrev ut i alla vilket ger intrycket av
>att du avser vem som ansvarar för vad.
Jag menade precis vad jag skrev. De olika nivåerna avser olika contexts.
>En annan sak du inte tagit med är att renderingen sker på processens context
>vilket gör att uppdateringen kan gå avsevärt slöare om den har låg
>prioritet.
I realiteten är alla tasks Waiting. Det kan gå avsevärt slöare om du kör
Imagine samtidigt, men det är en annan sak.
>Det finns standard BOOPSI-objekt med mer avancerad grafik än tex GadTools
>som inte lider av detta. Nackdelen är att väl att alla MUI-objekt har ett
>avancerat standard gränssnitt oavsett om implementeringen som sådan behöver
>det, eller hur?
Nja, mer avancerad grafik är det nog inte. Den mest avancerade klassen är
nog SysImage och den ritar 'endast lite streck' (som den dessutom cachar)
Problemet med mer anvancerad grafik är att OM_RENDER blockerar datorn (då
den exekveras av input.device) Inte ens muspekaren kommer att röra sig!
Det är det som händer i GrapeVine när mycket text skall scrollas.
>>>Inte om programmet inte explicit behöver det. Själv kör jag GadOutline som
>>>GUI-engine och de effekter som MUI uppvisar under tung belastning visar sig
>>>inte med GadOutline. Dock så erbjuder ju GO inte samma fina
>>>högnivåfunktioner som MUI. MUI är mer än en GUI-layoutengine.
SB>> Nu jämför du äpplen och päron så det du säger saknar relevans.
>Gör jag? Utåt sett så gör GO/MUI samma sak i detta fallet, de ansvarar för
När du själv säger att MUI är mer en GUI-layoutengine så säger du ju själv
att det inte är samma saker som jämförs. Dessutom har MUI många funktioner
som inte GO har och det är (tyvär) inte gratis. Att du sedan inte
uppskattar dessa funktioner är bara synd (eftersom du (kanske) retar dig på
kostnaderna för dom)
>att fönstret layoutas om efter en resize. Inga av MUI:s fancy funktioner
>behövs för detta. Ändå tar det avsevärt längre tid för MUI att prestera
>samma sak.
Det beror på att MUI hanterar BOOPSI object. Det gör (såvitt jag vet) inte
GO. Dock så är BOOPSI framtiden då man har högre flexibilitet. (Och kortare
utvecklings tider)
>Så att mina måhända enkla tester av att jämföra avancerade GUI:n av MUI/GO
>typ som ger två olika känslor av snabbhet beror på något annat än att det
>ena går långsammare än det andra? Trots att det GUI som GO hade innehöll
>avsevärt fler gadgets :D
Kan du precisera dig? Jag gjorde för skojs skull ett DOpus liknande program
(bara gui'et) för ett tag sedan och jag kunde inte finna att det var slöare
än det riktiga DOpus (v4.12)
>Om programmet som har ansvar för att grafiken uppdateras så har det en viss
>betydelse hur fort det programmet får CPU. Om vi tar ett extremfall:
>Låt din process ligga på -128 om den nu får ett meddelande om att GUI:et
>behöver uppdateras så talar det om att det går alldeles utmärkt eftersom den
>inget annat har för sig. Eftersom de objekt som den skapat kommer att
>exekveras på den processens context så kommer de också att använda den tid
>som de får vilken kan bli väldigt liten vid en prioritet -128.
>Däremot om Intuition skickar meddelandet att fönstret resizats och
>programmet svarar att det går bra uppdateras ditt fönster snabbare eftersom
>Intuiton kör på input.devices context dvs 20 och därmed tar den tid det
>behöver ÄVEN om det finns andra processer från 19 ner till -128.
>Beroende på hur uppläggningen ser ut så blir det mer eller mindre effekt.
Men om ditt object är en HTML klass som kan ta upp till 1 sekund att räkna
om? Gissa om muspekaren kommer att frysa under tiden.
Lösningen på detta problem finns inte i dagens AmigaOS (och inte i något
annat os heller) Skulle man få för sig att lösa detta skulle lösningen inte
bli snabbare förän på en redan lagom snabb dator. Den andra lösningen är
att köra på en snabbare processor. Detta är _faktiskt_ inte så långsökt.
Man behöver inte gå till ytterligheter som Windows men Amigan har faktiskt
kört på ~25/mhz 030's ganska länge medan programvaran krävt något mer.
Jag har _inte_ filosofin att anpassa hårdvaran efter mjukvaran, men det är
ganska löjligt att gnälla på MUI (i IBrowse) när en jpeg bild tar ännu mer
tid. Folk tycker att MUI gör IBrowse oanvändbart på en A500 men ärligt
talat är det inte designat för en A500.
Förutom det är en sak som tar mycket tid i MUI grafiken. Tyvär är det svårt
att göra MUI med de 'fancy' funktioner samt utan overhead när man bara har
vanliga inställningar. Jag har pratat med stuntzi om en hårdkodad version
(med bara GadTools look) av MUI, men han har inte velat lyssna på det örat:(
>Med context så avses alltså inte bara miljön utan även den prioritet som
>processen innehar. Stuntz kanske avser något annat med context, jag vet
>inte.
Context är helt oberoende av hur snabbt eller långsamt en process är.
Med context avses en task med hela dess interna miljö (där prioriteten
ingår)
>Det är iaf min oexpert förklaring varför MUI beter sig som det gör i vissa
>fall. I slutändan, vilket är det som räknas är iaf MUI slöare än något annat
>layout library jag sett vilket torde bero på något. Om du anser dig vara
>expert på MUI så kanske du kan förklara det.
BGUI är ca dubbelt så slött som MUI. (I alla fall då jag testade sist)
>Dessutom, de tester jag gjort med MUI är ren installation v3 utan fancy
>saker. Alla program kör sina defaults.
Vilka program har du testat? Jag tror ärligt talat inte att det gör att
göra en ärlig jämförelse eftersom MUI program ofta är komplexa i sig.
(Om AMosaic ingår som ett jämförelse object så ber jag dig ta bort det.
AMosaic skulle inte bete sig särskilt väl utan MUI heller)
Mikael Berglund
In a message 30-Jan-96 22:40:44 Stefan Burstrom <burs...@df.lth.se> wrote:
SB> Ja, intuition (läs: input.device) rendrerar alla BOOPSI object som är
SB> subklasser av ImageClass och GadgetClass
Det var väl det jag trodde. Men Intuition är väl bara kopplad till
input.device för input.device är ju ett eget device i sig.
SB> Ja, men det är faktiskt inte så farligt mycket tid som går åt här.
Kanske inte men det kostar iaf. Hur mycket är ju svårt att säga men det är
inte helt gratis skulle jag tippa :D
SB> Detta är faktiskt en smaksak. Jag har mött folk som föredrar båda
SB> typerna.
Jag har inte träffat någon som föredrar MUI:s lösning.
SB> (THOR tex kan man trycka sig fördärvad på 'Abort' vilket jag inte
SB> gillar.)
Men det är ju för att THOR väntar på ett event och även om knappen reagerar
så kan inte THOR göra något åt det eftersom den kallat på någon läcker
funktion i socket.library. Har talat med en av programmerarna om det och
sade att som TCP/IP stacken är uppbyggd nu så är THOR tvungen att göra så.
Det finns inget sätt att sas bryta en väntan på ett packet. Man får snällt
vänta till det blir timeout, vilken inte heller går att ställa om tydligen.
SB>>> Det enda i MUI som tar längre tid är att rendrera gadgeten men det är
SB>>> inte så konstigt eftersom de flesta mui gadgets är mycket mer grafiskt
SB>>> krävande.
>>Hm, ett par oklarheter. input.device handhar väl inte själva renderingen
>>eftersom Intuiton ansvarar för detta?
SB> Nåja, det blev lite begrepsförvirring.
SB> Intuition finns inte som task untan den är beroende av att input.device
SB> talar om vad som händer via funktionen Intuition()
Jodå, så långt är jag med. Men Intuition sitter ju bara som ett filter på
meddelande kedjan den är ju inte del av input.device i sig. Om Intuition
inte får för sig att meddelandet avser något som Intuition ansvarar för så
trillar ju meddelandet vidare till andra applikationer som använder
input.device.
SB> I realiteten är alla tasks Waiting. Det kan gå avsevärt slöare om du kör
SB> Imagine samtidigt, men det är en annan sak.
Nja, skulle jag vilja säga. Det är ju miljöberoende hur mycket CPU en
process får och en sådan sak är det kanske inte så smart att förlita sig på
som programmerare vad olika användare kör för program.
>>Det finns standard BOOPSI-objekt med mer avancerad grafik än tex GadTools
>>som inte lider av detta. Nackdelen är att väl att alla MUI-objekt har ett
>>avancerat standard gränssnitt oavsett om implementeringen som sådan behöver
>>det, eller hur?
SB> Nja, mer avancerad grafik är det nog inte. Den mest avancerade klassen är
SB> nog SysImage och den ritar 'endast lite streck' (som den dessutom cachar)
SB> Problemet med mer anvancerad grafik är att OM_RENDER blockerar datorn (då
SB> den exekveras av input.device) Inte ens muspekaren kommer att röra sig!
SB> Det är det som händer i GrapeVine när mycket text skall scrollas.
Ändå så tycks det mig vid olika tester att MUI:s objekt låser maskinen för
längre tider vilket också borde gälla för standard BOOPSI-objekten eftersom
de också exekverar på samma context.
SB> När du själv säger att MUI är mer en GUI-layoutengine så säger du ju
SB> själv att det inte är samma saker som jämförs. Dessutom har MUI många
SB> funktioner som inte GO har och det är (tyvär) inte gratis. Att du sedan
SB> inte uppskattar dessa funktioner är bara synd (eftersom du (kanske) retar
SB> dig på kostnaderna för dom)
Men om vi tittar på det speciella fallet jag nämnde så har ju inte MUI mer
att göra än vad GO har. Så många speciella funktioner i just MUI nyttjas
förmodligen inte iaf inte i så stor grad att man skulle reagera på att
MUI-hanterade GUI:n är avsevärt slöare.
>>att fönstret layoutas om efter en resize. Inga av MUI:s fancy funktioner
>>behövs för detta. Ändå tar det avsevärt längre tid för MUI att prestera
>>samma sak.
SB> Det beror på att MUI hanterar BOOPSI object. Det gör (såvitt jag vet)
SB> inte GO. Dock så är BOOPSI framtiden då man har högre flexibilitet. (Och
SB> kortare utvecklings tider)
Jomen se, GO hanterar BOOPSI fullt ut. Titta på gadoutline.library 3.62
BETA. Dock så påstår de inledande doc:sen att den inte gör det men Dianne
hade inte hunnit skriva dessa därav BETA labeln.
SB> Kan du precisera dig? Jag gjorde för skojs skull ett DOpus liknande
SB> program
SB> (bara gui'et) för ett tag sedan och jag kunde inte finna att det var
SB> slöare än det riktiga DOpus (v4.12)
Kan något vara så mycket slöare än DOpus? :D Det är väl de flestas stora
'grudge' med DOpus.
Jag har använt få MUI-applikationer, av förståeliga skäl, men ett exempel
som jag möter väldigt ofta är tex AMosaic/MUIAdt. Om dessa har sina fönster
uppe så tar det längre tid för dessa att uppdatera sig vid en sådan enkel
sak som tex djuparrangering än några andra standard GUI:n oavsett hur
avancerade de ser ut. Om tex AMosaic väntar på något så uppdateras ju inte
grafiken om man djuparrangerar (av samma anledning som THOR inte reagerar på
Abort-knappen). Men djuparrangerar man Thor så hänger grafiken med.
>>Om programmet som har ansvar för att grafiken uppdateras så har det en viss
>>betydelse hur fort det programmet får CPU. Om vi tar ett extremfall:
>>Låt din process ligga på -128 om den nu får ett meddelande om att GUI:et
>>behöver uppdateras så talar det om att det går alldeles utmärkt eftersom den
>>inget annat har för sig. Eftersom de objekt som den skapat kommer att
>>exekveras på den processens context så kommer de också att använda den tid
>>som de får vilken kan bli väldigt liten vid en prioritet -128.
>>Däremot om Intuition skickar meddelandet att fönstret resizats och
>>programmet svarar att det går bra uppdateras ditt fönster snabbare eftersom
>>Intuiton kör på input.devices context dvs 20 och därmed tar den tid det
>>behöver ÄVEN om det finns andra processer från 19 ner till -128.
>>Beroende på hur uppläggningen ser ut så blir det mer eller mindre effekt.
SB> Men om ditt object är en HTML klass som kan ta upp till 1 sekund att
SB> räkna om? Gissa om muspekaren kommer att frysa under tiden.
Om det är ett BOOPSI-obejekt, ja. Men oavsett så är overheaden lägre än för
motsvarande MUI-objekt eftersom MUI är där och trasslar INNAN ojektet ens
ser meddelandet.
Dessutom så skulle jag starkt ifrågasätta det smarta i att låsa datorn under
en sådan lång tid som en sekund. Då är det antagligen bättre att låta själva
beräkningen ske på lägre prioritet och sedan trycka ut den så snabbt
grafiken tillåter.
SB> Lösningen på detta problem finns inte i dagens AmigaOS (och inte i något
SB> annat os heller) Skulle man få för sig att lösa detta skulle lösningen
SB> inte bli snabbare förän på en redan lagom snabb dator. Den andra
SB> lösningen är att köra på en snabbare processor. Detta är _faktiskt_ inte
SB> så långsökt. Man behöver inte gå till ytterligheter som Windows men
SB> Amigan har faktiskt kört på ~25/mhz 030's ganska länge medan programvaran
SB> krävt något mer. Jag har _inte_ filosofin att anpassa hårdvaran efter
SB> mjukvaran, men det är ganska löjligt att gnälla på MUI (i IBrowse) när en
SB> jpeg bild tar ännu mer tid. Folk tycker att MUI gör IBrowse oanvändbart
SB> på en A500 men ärligt talat är det inte designat för en A500.
Det har ingen emotsagt dig på heller. Jag kör en A3000/030-28MHz och jag
tycker inte MUI är acceptabelt ur snabbhetssynpunkt. Vissa accepterar det
och vissa gör det inte. Att så många inte tycker om/accepterar MUI tyder på
att det är något hos MUI som retar folk. Dessutom så är motståndet ganska
spritt över hårdvaran tycker jag det verkar som. Jag har sällan sett sådan
uppdelning av folk som just vid tex MUI.
SB> Förutom det är en sak som tar mycket tid i MUI grafiken. Tyvär är det
SB> svårt att göra MUI med de 'fancy' funktioner samt utan overhead när man
SB> bara har vanliga inställningar. Jag har pratat med stuntzi om en
SB> hårdkodad version
SB> (med bara GadTools look) av MUI, men han har inte velat lyssna på det
SB> örat:(
Kanske det skulle vara en lösning för de som inte gillar MUI. Jag kör själv
MUI-applikationer där det inte finns en likvärdig standard applikation och
jag har alltid kört på standard inställningarna. Jag bryr mig inte om att ha
en miljon bilder som jag kan använda då jag aldrig använder dem. Dessutom så
är ju inte alla kompletta med alla olika typer av bilder.
Jag tror dock inte det är så lätt att göra en 'light' version. Den mesta
tiden går antagligen åt till MUI:s interna saker och det kan man ju inte
ändra på utan att göra den fullständigt inkompatibel med existerande
programvara. Så det man tjänar på att köra standard grafik är kanske inte så
stort.
SB> Context är helt oberoende av hur snabbt eller långsamt en process är.
SB> Med context avses en task med hela dess interna miljö (där prioriteten
SB> ingår)
Då talar vi om samma sak då iaf :D
SB> BGUI är ca dubbelt så slött som MUI. (I alla fall då jag testade sist)
Jag har BGUI.library men jag har inget program som använder det :D
SB> Vilka program har du testat? Jag tror ärligt talat inte att det gör att
SB> göra en ärlig jämförelse eftersom MUI program ofta är komplexa i sig.
De som tvingats på mig som MUIEMail(namet?), MUIAdt, AMosaic.
Prefsprogrammet samt testprogrammen och säkert några till som jag tagit hem
ovetande om att det är program som använder MUI. Jag är noggrannare idag med
vad jag plockar hem. Jag har trots det dock både MUI:s dev och user arkiv
hemma :D
MUIAdt, AMosaic använder jag fortfarande men skulle vilja dumpa dem vid
bästa tillfälle. AMosaic ligger på fallrepet genom att jag fått tag på AWeb
men som jag inte tittat på ännu. IBrowse ligger på listan men har inte
hämtad hem den ännu (den kör ju dessutom ------ MUI ------, huga ;D).
SB> (Om AMosaic ingår som ett jämförelse object så ber jag dig ta bort det.
SB> AMosaic skulle inte bete sig särskilt väl utan MUI heller)
Grafiken i AMosaic har förmodligen väldigt lite att göra med hur AMosaic
fungerar i övrigt. När AMosaic fungerar så visar den inga skillnader mot
andra MUI-applikationer vad jag sett. Sedan att AMosaic är så buggigt i sig
kan man ju inte lasta MUI för, vilket en del felaktigt gör.
Mikael Berglund
In a message 04-Feb-96 02:08:35 Stefan Burstrom <burs...@df.lth.se> wrote:
SB> Intuition är ingen egen task. Allt som intuition rendrerar 'själv'
SB> rendreras av input.device
Den renderar på input.device context. Intuition/input.device är inte samma
sak vilket var vad jag menade.
SB>>> Detta är faktiskt en smaksak. Jag har mött folk som föredrar båda
SB>>> typerna.
>>Jag har inte träffat någon som föredrar MUI:s lösning.
SB> Men du verkar föredra THOR ;)
Ja, det är den bästa läsare för news. Jag skulle föredra Spot eftersom den
inte är så generell men jag har inte iddas sätta upp AmiGate. THOR använder
väl inte MUI heller vad jag vet.
SB> Det går alldeles utmärkt. Synd att THOR grabbarna inte har uptäckt det ;)
Tja, då tycker jag du skall upplysa dem om det. Oavsett så är
låsningsproblemet detsamma med tex AMosaic. Du som vet kanske kan tala om
vilka funktioner man skall använda.
SB> Vad menar du med låser sig? Att låsa sig betyder att rendrera under
SB> input.device för lång tid.
Ja, vilket de gör trots att MUI-GUI:et inte är speciellt avancerat. Om det
hade gällt fräsiga bakgrunder och annat krafs okej, men hos mig så ser inte
MUI-applikationerna ut mycket mer annorlunda än något annat standard-GUI.
SB> Och ändå älskar folk DOpus. Strange!
Men slöheten är också det som alla klagar på. Själv kör jag SID, snabb som
ögat men inte lika funktionsfylld.
SB> Vänta lite, kör du smart refresh eller simple refresh?
Simple refresh (enligt CGWBPPattern :D). Smart drar mer minne men eftersom
det skall kvicka upp grafiken så funderar jag på det.
SB> IBrowse rocks!
Jag har som förstått det :D Testade AWeb i helgen och det var mycket
trevligt, men jag skall ge IBrowse en chans också (trots MUI :D).
>>Grafiken i AMosaic har förmodligen väldigt lite att göra med hur AMosaic
>>fungerar i övrigt. När AMosaic fungerar så visar den inga skillnader mot
>>andra MUI-applikationer vad jag sett. Sedan att AMosaic är så buggigt i sig
>>kan man ju inte lasta MUI för, vilket en del felaktigt gör.
SB> Nja, Att tex resiza fönstret I Amosaic är slött beror på att resize
SB> rutinerna i xwindows koden är långsam. Senast jag testade var IBrowse
SB> ca 30 ggr snabbare än AMosaic vid stora sidor.
Låter som om IBrowse är något man borde testa.
SB> BTW, MUI är mycket snabbare på ett grafikkort.
Picasso II.