/ Forside / Teknologi / Udvikling / Delphi/Pascal / Nyhedsindlæg
Login
Glemt dit kodeord?
Brugernavn

Kodeord


Reklame
Top 10 brugere
Delphi/Pascal
#NavnPoint
oldwiking 603
jrossing 525
rpje 520
EXTERMINA.. 500
gandalf 460
gubi 270
DJ_Puden 250
PARKENSS 230
technet 210
10  jdjespers.. 200
Over 32768 pixels i højden i et TPanel
Fra : Toke Eskildsen


Dato : 04-10-03 22:22

"640KB should be enough for anyone".

Eller i en lidt mere moderne udgave: Ingen har behov for at placere
elementer på koordinater udenfor -32767 til 32768.

Nå ja, når man har over 42 billeder af 800 pixels højde og starter på
position 0 bliver 32768 pludselig ret lidt.


Jeg benytter Delphi 6, men så vidt jeg kan udlede er det en begrænsning
i Windows. Der må være andre der har haft samme problem, men jeg har
ikke kunnet finde nogen færdig løsning. Nogen forslag?
--
Toke Eskildsen - http://ekot.dk/

 
 
Lars B. Dybdahl (04-10-2003)
Kommentar
Fra : Lars B. Dybdahl


Dato : 04-10-03 22:32

Toke Eskildsen wrote:
> Jeg benytter Delphi 6, men så vidt jeg kan udlede er det en begrænsning
> i Windows. Der må være andre der har haft samme problem, men jeg har
> ikke kunnet finde nogen færdig løsning. Nogen forslag?

Du kunne evt. programmere direkte op mod Windows eller indrette dit program
sådan, at du ikke skal bruge hele skalaen.

Lars.

--
Freelance programmør
Delphi brugergruppen DAPUG: http://dapug.dk/
Delphi oversættelsesværktøjer: http://dxgettext.sf.net/

Toke Eskildsen (04-10-2003)
Kommentar
Fra : Toke Eskildsen


Dato : 04-10-03 23:05

Lars B. Dybdahl wrote:

> Du kunne evt. programmere direkte op mod Windows

Joeh... Det kunne jeg vel. Jeg ville nu gerne slippe for at skulle
sætte mig ind i det blot for at kunne få et større areal til rådighed.

> eller indrette dit program sådan, at du ikke skal bruge hele
> skalaen.

En reel mulighed, men det er ikke trivielt, når elementerne skal kunne
reagere på input. Jeg kunne måske lave noget med at oprette en
scrollbare og et Panel og så ellers flytte de relevante elementer ind
på panelet det rette sted, når scrollbaren blev rykket...
--
Toke Eskildsen - http://ekot.dk/

Lars B. Dybdahl (05-10-2003)
Kommentar
Fra : Lars B. Dybdahl


Dato : 05-10-03 10:14

Toke Eskildsen wrote:
>> eller indrette dit program sådan, at du ikke skal bruge hele
>> skalaen.
> En reel mulighed, men det er ikke trivielt, når elementerne skal kunne
> reagere på input. Jeg kunne måske lave noget med at oprette en
> scrollbare og et Panel og så ellers flytte de relevante elementer ind
> på panelet det rette sted, når scrollbaren blev rykket...

Nemlig... Kønt er det ikke men systemet blev bare ikke designet til mere
end 32768 pixels.

Lars.

--
Freelance programmør
Delphi brugergruppen DAPUG: http://dapug.dk/
Delphi oversættelsesværktøjer: http://dxgettext.sf.net/

Toke Eskildsen (04-10-2003)
Kommentar
Fra : Toke Eskildsen


Dato : 04-10-03 22:36

Toke Eskildsen wrote:

> Nå ja, når man har over 42 billeder af 800 pixels højde og starter
> på position 0 bliver 32768 pludselig ret lidt.

Og for ikke at spilde jeres tid kunne det være jeg skulle beskrive lidt
nøjere hvad jeg vil...

Jeg roder med http://ekot.dk/JPEGCrops/ der kan beskære JPEG billeder.
Billederne skal vises flere ad gangen sammen med nogle GUI elementer
(TextField, Button, CheckBox, ComboBox...). Det er altså ikke nok blot
at tegne grafikken, der skal også reageres på input til hvert billede.

For nu at forværre tingene så kører jeg med flere rækker af billeder.
--
Toke Eskildsen - http://ekot.dk/

Jens Andersen (09-10-2003)
Kommentar
Fra : Jens Andersen


Dato : 09-10-03 15:34

"Toke Eskildsen" <darkwing@daimi.au.dk> skrev i en meddelelse
news:Xns940AEE07F53A1tokeeskildsen@130.133.1.4...
> "640KB should be enough for anyone".
>
> Eller i en lidt mere moderne udgave: Ingen har behov for at placere
> elementer på koordinater udenfor -32767 til 32768.
>
> Nå ja, når man har over 42 billeder af 800 pixels højde og starter på
> position 0 bliver 32768 pludselig ret lidt.

En ide kunne eventuelt være at lave en data struktur der indeholder filnavne
og properties (dvs. inkluderende de ændre properties...) og så lave en slags
array/linked list af de strukturer.
Dernæst kan du forholdsvist nemt programmere <- og -> knapper og kan dermed
slippe med at vise f.eks. 3 billeder af gangen. Evt. kan du nok loade
billederne ind i hukommelsen og dermed få dem vist hurtigere når man
trykker -> men jeg tror ikke det gør den store forskel medmindre det er
meget store billeder..
Ved ikke om det er noget du kan bruge og det er egentligt ikke en løsning,
mere et workaround.. Men det burde virke og det er forholdsvist simpelt...
Mvh Jens Andersen



Toke Eskildsen (10-10-2003)
Kommentar
Fra : Toke Eskildsen


Dato : 10-10-03 07:07

Jens Andersen wrote:

> En ide kunne eventuelt være at lave en data struktur der
> indeholder filnavne og properties (dvs. inkluderende de ændre
> properties...) og så lave en slags array/linked list af de
> strukturer. Dernæst kan du forholdsvist nemt programmere <- og ->
> knapper og kan dermed slippe med at vise f.eks. 3 billeder af
> gangen.

Jeg sidder lige nu og roder med noget lignende: Almindelige
TWincontrols pakkes ind i hver deres simple objekt der blot har en
position der benytter integers i stedet for shortints (eller hvad de nu
hedder). De sorteres efter vertikal position og flyttes på plads efter
scrollbarens position.

Der er bare en del ting der driller. Når et TWinControl gøres
invisible, mister det fokus, så det skal eksplicit generhverves når det
bliver synligt igen. Og jeg skal selv håndtere skift af fokus til en ny
TWinControl ved at flytte området så den nye TWinControl bliver synlig.
Der er sikkert andre smarte ting som jeg har overset.

> Evt. kan du nok loade billederne ind i hukommelsen og
> dermed få dem vist hurtigere når man trykker -> men jeg tror ikke
> det gør den store forskel medmindre det er meget store billeder..

Det er til behandling af fotografier. De er allesammen JPEGs og selv om
jeg laver lidt smart loading, tager det stadig et sekunds tid at åbne
et af rimelig størrelse og sætte det ind i listen. Lile nu starter jeg
med at generere nedskalerede udgaver af alle ønskede billeder. Det
giver en vis starttid, men glimrende respons bagefter.

....Jeg kunne selvfølgelig eksperimentere med kun at have de billeder
inde i hukommelsen som var synlige og som lå i umiddelbat nærhed af de
synlige billeder...
--
Toke Eskildsen - http://ekot.dk/

Ove Kjeldgaard (10-10-2003)
Kommentar
Fra : Ove Kjeldgaard


Dato : 10-10-03 11:06

Toke Eskildsen <darkwing@daimi.au.dk> wrote:

>...Jeg kunne selvfølgelig eksperimentere med kun at have de billeder
>inde i hukommelsen som var synlige og som lå i umiddelbat nærhed af de
>synlige billeder...

Og så cache de billeder der har været vist?


--
Med venlig hilsen, Ove Kjeldgaard, nospam AT privat DOT dk
Natur og Friluftsliv: <http://hiker.dk>

Toke Eskildsen (11-10-2003)
Kommentar
Fra : Toke Eskildsen


Dato : 11-10-03 08:58

Ove Kjeldgaard wrote:

> Og så cache de billeder der har været vist?

Jeg forstår ikke helt ideen med at cache billederne (på harddisken) i
stedet for blot at lade dem blive i RAM? Windows smider dem jo over i
swapfilen, hvis der begynder at blive hukommelsesproblemer, så er
effekten ikke ca. det samme?
--
Toke Eskildsen - http://ekot.dk/

Ove Kjeldgaard (11-10-2003)
Kommentar
Fra : Ove Kjeldgaard


Dato : 11-10-03 12:48

Toke Eskildsen <darkwing@daimi.au.dk> wrote:

>Jeg forstår ikke helt ideen med at cache billederne (på harddisken) i
>stedet for blot at lade dem blive i RAM? Windows smider dem jo over i
>swapfilen, hvis der begynder at blive hukommelsesproblemer, så er
>effekten ikke ca. det samme?

Hvis jeg husker ret, så var det dit browserwindue for åbning af JPG'er?

Og jeg mente cache i RAM, frem for at skulle indlæse og bearbejde igen fra
harddisken.


--
Med venlig hilsen, Ove Kjeldgaard, nospam AT privat DOT dk
Natur og Friluftsliv: <http://hiker.dk>

Toke Eskildsen (13-10-2003)
Kommentar
Fra : Toke Eskildsen


Dato : 13-10-03 11:47

Ove Kjeldgaard wrote:

> Hvis jeg husker ret, så var det dit browserwindue for åbning af
> JPG'er?

Jeps.

> Og jeg mente cache i RAM, frem for at skulle indlæse og bearbejde
> igen fra harddisken.

Jeg forstår desværre ikke din pointe. Lige nu er alle de nedskalerede
udgaver i RAM hele tiden, så der er ingen genlæsning fra harddisken.
--
Toke Eskildsen - http://ekot.dk/

Ove Kjeldgaard (13-10-2003)
Kommentar
Fra : Ove Kjeldgaard


Dato : 13-10-03 16:28

Hej Toke

Toke Eskildsen <darkwing@daimi.au.dk> wrote:

>Jeg forstår desværre ikke din pointe. Lige nu er alle de nedskalerede
>udgaver i RAM hele tiden, så der er ingen genlæsning fra harddisken.

Så vil jeg vove at gentage det jeg oprindelig svarede på:

>>...Jeg kunne selvfølgelig eksperimentere med kun at have de billeder
>>inde i hukommelsen som var synlige og som lå i umiddelbat nærhed af de
>>synlige billeder...


--
Med venlig hilsen, Ove Kjeldgaard, nospam AT privat DOT dk
Natur og Friluftsliv: <http://hiker.dk>

Søg
Reklame
Statistik
Spørgsmål : 177580
Tips : 31968
Nyheder : 719565
Indlæg : 6409081
Brugere : 218888

Månedens bedste
Årets bedste
Sidste års bedste