Re: [Fenfire-dev] Re: Viiko ntakainen päivitys

[Tuomas Lukka]

(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