[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Fenfire-dev] Re: Viiko ntakainen päivitys
From: |
Tuomas Lukka |
Subject: |
Re: [Fenfire-dev] Re: Viiko ntakainen päivitys |
Date: |
Mon, 6 Oct 2003 09:22:19 +0300 |
User-agent: |
Mutt/1.5.4i |
(cc ff-dev, could we try to let others in on this discussion?)
On Sun, Oct 05, 2003 at 11:33:46PM +0300, Asko Soukka wrote:
> > > perjantaina, 26. syyskuuta 2003 klo 11:42, Tuomas Lukka kirjoitti:
> > > > Niin, toinen kysymys on, onko minun järkevää vaatia pikkumuutoksia
> > > > vai tehdä ne itse pätsiin?
> > >
> > > Dokumentoinnin kannalta ainakin kannattaa heittää pienemmätkin
> > > muutokset takaisin, samassa hengessä kuin PEGit. Ainakin jos patchi
> > > tulee projektin sisältä. Parempi dokumentointi maksanee kuitenkin
> > > itsensä ajassa myöhemmin takaisin :)
> >
> > Mut entäs muut? Esim. ne luokkien nimet?
>
> Harkinnan varaista. Jos mitään muuta ei patchissa olisi ollut kuin ne
> luokkien nimet, joita tässä tapauksessa ei olisi edes tarvinnut
> muuttaa moneen paikkaan, en olisi pahastunut, vaikka olisit ne
> korjannut. Nyt kuitenkin oli dokumentoinnin parantamistakin, joten
> minun olisi pitänyt korjata ne luokkienkin nimet.
>
> Minulle kuitenkin kävi niin nolosti, että olin siivonnut
> postilaatikostani alkuperäiset korjausehdotuksesi niiden kommentoinnin
> jälkeen ja unohdin millaisiksi ne luokkien nimet olisi tullut korjata
> :(
ConstructorParameter_float jne, eli suurella kirjaimella alkavaksi
ja sanomaan, että kyse on *konstruktori*parametrista.
> > > jo yhden liian suuren dokumentin transkluointi voi tehdä koko
> > > kanvaksen käyttökelvottoman hitaaksi
> >
> > "Liian suuren" = mitä tässä tapauksessa
>
> Riippuu tietenkin käytetystä koneesta, mutta mitä enemmän dokumentissa
> on sivuja, sitä raskaammalta sen poijukin vaikuttaa.
Mut niin kuin näppituntumaa? Onko se 10 sivua vai 10000 sivua?
> Lopputuloksena
> olen joutunut tekemään yhden transkluusion kanvaksia.
Auts. Toi on sitten varmaan aika tärkeä korjata pian.
Eli nyt prioriteetti:
1) katoavat fontit
2) (ellei mennyt jo) invalid coordsys ind
3) tuo isot dokumentit -bugi
> > > onko teared viewportia testattu tässä?
> > Ongelma on, että silloin ei tiedä mistä kohdasta artikkelia
> > viittaus on. Parempi esim. laittaa teksturoimaton versio useimmista
> > sivuista tms. katkaista artikkeli.
>
> Vaikea tehdä kompromisseja käyttöliittymässä pelkästään sen vuoksi,
> että vanhemmista koneista loppuu teho :/ Jos olisi luotettava
> benchmarking, niin ehkä FenPDF osaisi seurata itseään ja "optimoida"
> toimintaasta... tässä esimerkiksi vain lähimpänä olevan
> artikkelipoijun kaikki sivut olisi teksturoitu. Tosin tuo lähestyisi
> jo sitä pelottavaa älykkyyttä.
Ei, tuo ei ole älykkyyttä, vaan ihan helppoa adaptiivisuutta. Älykkyyttä
olisi, jos pitäisi teksturoida se poiju, johon tällä hetkellä näkyvistä
fokuksista ja "käyttäjämallista" päätellen kohta menet.
Meillä *on* jo adaptiivisuutta tuolla tasolla: tekstuurien mipmap-tasoja
ladataan - miten muuten luulet että meillä voi olla pakattuna 1GB tekstuureita
;)
> Entäs hirmuisen pitkien artikkelien poijut, joissa yksittäiset sivut
> muistaakseni näkyvät todella pieniä. Kalansilmä poijuissa voisi olla
> raskas ratkaisu, mutta kuinka se on toiminut?
Ei kalansilmäkään ole mahdoton: huomaa, että me ei vielä edes käytetä
impostereita (eli että renderöidään tekstuuriin poijun kuva ja käytetään
sitä), mikä auttaisi kanssa jo paljon.
> > > - paljon transkluusioita keräävät kanvakset hyötyisivät, jos
> > > niitä voisi luoda myös toiseen suuntaan (ja poijut saisi
> > > jaettua kanvaksen molemmille puolille)
> > >
> > > esimerkiksi poijun hiirimenussa "unlink buoyn" lisäksi
> > > toiminto "swap link direction"
> >
> > Joo, kysymys vaan on: *miten* tuo toteutetaan järkevästi...
>
> Tai kuten structlinkissä voisi valita suunnan, myös
> transkluusiossa voisi. Tosin sekoittanee taas hiirimenua.
Joo, mut tarkoitin siis myös rakenteen kannalta. Rakenteessahan transkluusiota
ei eksplisiittisesti esitetä...
Tuomas