Discussion :

[Jipété]

Yep !

Je viens de faire un test avec BGRABitmap

Le FireFoxLarge est chargé, mais converti en niveaux de gris. Pourquoi ? aucune idée
Pièce jointe 399427

Et en plus tu lui as cassé la géométrie : au départ cette image est presque carrée et là on voit bien qu'elle l'est moins...

Si on ne le fait pas c'est parce que la mémoire est linéaire et qu'on précharge toujours la valeur et des valeurs contiguës.
Et en respectant ce fonctionnement, on évite autant que faire se peut des défauts de cache (cache misses)

Qui ça, "on" ?
Moi je ne fais rien du tout, je me contente de trafiquer les couleurs des pixels.

+++

j'attends les contre-exemples, ou qu'on me dise où je me suis trompé.

T'es qu'un imbécile, mon gars : t'as oublié que commencer à 0,0 te masquait un problème !

x1,y1,x2,y2 sont des coordonnées, mets-toi ça dans le crâne !
Commence à 10,5 et tu vas constater qui tu n'auras rien, comme s'il y avait un test vérifiant que x2 doit être > à x1 et pareil pour les y.

Donc en fait, il faut la jouer ainsi :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
procedure TForm1.Button6Click(Sender: TObject);
var
  w,h: integer;
  offsetL,offsetT: integer; // new !
begin
  offsetL := 2;  offsetT := 1;
  w := 3;  h := 2;
  with Form1.canvas do begin
    brush.style := bsSolid;
    brush.color := $80FF00;
    FillRect(rect(offsetL, offsetT, offsetL + w, offsetT + h));
  end;
end;

Et comme ça on démarre le rectangle où on veut avec offsetL et T, et on lui donne la taille qu'on veut avec w et h.

+++
Merci à J.P pour sa proposition que les linuxiens regardent avec la langue qui traîne par terre,
D'un autre côté, sans le code, c'est beau c'est bien mais on n'en fait rien,

pour retailler l'image en 28106 x 16000 en utilisant lanczos il lui faut une dizaine de secondes et pour sauvegarder l'image une quinzaine de secondes.

Oh lala, t'as une machine de guerre, toi !

Bonne journée et courage, on dirait qu'il va faire chaud...

[Jipété]

Les tests de tailles promis : j'ai enlevé l'enregistrement du fichier et son affichage dans le TImage générateurs de pagaille et consommateurs de ressources, j'ai également enlevé les divers "//" pour une meilleure lisibilité, et les tests ont été effectués hors EDI.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
procedure TForm1.Button2Click(Sender: TObject);
var
  w,h: integer;
begin
  w :=    512; h :=    68; // petites valeurs pour vérifier que tout va bien --> ok
 
  w := 262144; h :=   100; // valeur max Gimp pour "w" --> prog tué silencieusement par l'OS
  w :=  32768; h :=   100; // prog tué silencieusement par l'OS
  w :=  32768; h :=    10; // prog tué silencieusement par l'OS
  w :=  32768; h :=     1; // prog tué silencieusement par l'OS
 
  w :=  32767; h :=   100; // ok
  w :=  32767; h :=  1000; // ok
  w :=  32767; h := 10000; // ok
  w :=  32767; h := 22174; // ok
  w :=  32767; h := 22175; // message "out of memory" et après qq secondes, hop !, delog, bim !
 
  b24 := TBitmap.Create;
  b24.PixelFormat := pf24bit; // pf32bit ne fonctionne pas sur le canvas de la form
  b24.Width:=w;  b24.Height:=h;
  b24.Canvas.Pen.Color:=clLime; 
  b24.Canvas.Brush.Color:=clLime;
  b24.Canvas.Rectangle(0, 0, w, h);
  FormPaint(nil);
end;

Vous vous doutez bien que pour trouver h := 22174; // ok il y a eu plein d'essais intermédiaires, je ne les ai pas mis pour ne pas alourdir, je montre juste les valeurs à la frontière entre ok et bim ! si +1.

Malheureusement, il me vient l'idée de lancer le navigateur Web et The Gimp et de relancer le test avec la ligne w := 32767; h := 22174; // ok qui me joue alors le plan foireux out of memory, donc tout ça dépend de l'os et de la charge de la machine, la bonne question étant "mais pourquoi ça ne swappe pas ?"

Au final, j'ai peur qu'il n'y ait pas de réponse définitive aux limites de tailles et donc, comment prévenir l'utilisateur que ça va partir en vrille ?
Ou pas.
Aléatoirement...

[BeanzMaster]

Salut,

quelques petits soucis de connexion en ce moment chez moi . Je ne pouvais pas me connecter quand je le voulais.

J'ai donc écrit un pavé et j'en profite pour le poster

TRect est une coordonée

, plutôt un ensemble de 2 coordonées 2D définissant un plan 2D. Soit un point A (TopLeft) = X1,Y1 et un point B (BottomRight) = X2, Y2

Car je n'ais pas d'ou tu sort que Bottom/Left sont à l'extérieur. Ca c'est uniquement valable sous windows, car c'est la spéficiation de l'api qui est décrite comme ça. Et pourquoi Top et Left seraient à l'intérieur ?

Lazarus suit les spécifications de Delphi et Delphi les spécifications de Windows. Cette compréhension farfelue à cause de microsoft et de l'utilisation du TRect est récurrente depuis des décennies. L'utilisation du Rect(X,Y,Largeur, Hauteur) est valable que
pour les fonctions du canvas qui suivent les spécifications illogiques (pour moi) de microsoft http://ici(https://msdn.microsoft.co...v=vs.85).aspx)

Remarks
By convention, the right and bottom edges of the rectangle are normally considered exclusive.
In other words, the pixel whose coordinates are ( right, bottom ) lies immediately outside of the rectangle.
For example, when RECT is passed to the FillRect function, the rectangle is filled up to, but not including, the right column and bottom row of pixels.

Par convention, les bords droit et inférieur du rectangle sont normalement considérés exclusifs
En d'autres termes, le pixel dont les coordonnées sont (droite, bas) se trouve immédiatement à l'extérieur du rectangle
Par exemple, lorsque RECT est passé à la fonction FillRect, le rectangle est rempli jusqu'à la colonne de droite et la rangée inférieure de pixels

Le problème avec Lazarus (delphi aussi) c'est que cette spécifications n'est pas utilisé partout (le choix est laissé au développeur). Du coup c'est le bazard et faut y aller à tatons
Une des choses qui induisent en erreur c'est que dans la cas de la convention de windows, la fonction Rect est utilisé au lieu de Bounds. Mais la majorité des développeurs, y compris moi oublions que Bounds existe.
Elle est très méconnue. Et par simplicité nous utilisons "tous" RectDans la doc de Lazarus : (celui-ci est utilisé par Linux dans tous les cas)

type TRect = packed record
case Integer of
0: (
Left: LongInt; // Horizontal position of left edge --> Position horizontale du bord supérieur à gauche
Top: LongInt; // Vertical position of top edge --> Position verticale du bord supérieur en haut
Right: LongInt; // Horizontal position of right edge --> Position horizontale du bord inférieur à droite
Bottom: LongInt; // Vertical position of bottom edge --> Position verticale du bord inférieur en bas

Pour Windows TRect est définie ici : \Lazarus\fpcsrc\rtl\inc\typshrdh.inc

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
 
     public
       property Height: Longint read getHeight write setHeight;
       property Width : Longint read getWidth  write setWidth;
       property Size  : TSize   read getSize   write setSize;
       property Location  : TPoint read getLocation write setLocation;
       case Longint of
         0: (Left,Top,Right,Bottom : Longint);
         1: (TopLeft,BottomRight : TPoint);
         2: (Vector:TArray4IntegerType);
       end;

Dans la doc en ligne on peux lire :
http://TRect(https://www.freepascal....ts/trect.html), http://TRect(http://lazarus-ccr.sour...es/trect.html)
http://Delphi TRect(http://docwiki.e...m.Types.TRect)
http://Drawing with canvas(http://wi...ith_canvas/fr)
http://Un autre TRect(http://lazarus...ses/rect.html)

TRect est un piège mortel. Microsoft à mis son grain de sel et voilà.

Il faut également faire attention à l'ordre des unités déclarées dans uses, pour utiliser un certain type de TRect ou un autre

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
uses
  Windows,
  Classes,
  Graphics,
  SysUtils,

Maintenant
Dans C:\Lazarus\lazarus\lcl\graphics.pp

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
 
Type 
  TCanvas = class(TFPCustomCanvas)
  public
    procedure FillRect(const ARect: TRect); virtual; {$IFDEF HasFPCanvas1}reintroduce;{$ENDIF}
    procedure FillRect(X1,Y1,X2,Y2: Integer); {$IFDEF HasFPCanvas1}reintroduce;{$ENDIF}
 
Implementation
 
{------------------------------------------------------------------------------
  Method:   TCanvas.FillRect
  Params:   ARect
  Returns:  Nothing
 
 ------------------------------------------------------------------------------}
procedure TCanvas.FillRect(const ARect : TRect);
begin
  Changing;
  RequiredState([csHandleValid, csBrushValid]);
  LCLIntf.FillRect(FHandle, ARect, HBRUSH(Brush.Reference.Handle));
  Changed;
end;
 
{------------------------------------------------------------------------------
  procedure TCanvas.FillRect(X1,Y1,X2,Y2 : Integer);
 ------------------------------------------------------------------------------}
procedure TCanvas.FillRect(X1,Y1,X2,Y2 : Integer);
begin
  FillRect(Rect(X1,Y1,X2,Y2));
end;

Ici il y a déja une erreur FillRect aurais du être déclaré procedure TCanvas.FillRect(X1,Y1,W,H : Integer); pour une meilleur compréhension.

Sous Windows et Linux

LCLIntf.FillRect(FHandle, ARect, HBRUSH(Brush.Reference.Handle)); // appel la fonction native de Windows ou via la procedure déclaré dans le Widgetset (GTK, QT) utiliséDans Lazarus\fpcsrc\rtl\inc\typshrd.inc

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
 
function TRect.getWidth: Longint;
begin
  result:=right-left;
end;
 
function TRect.getHeight: Longint;
begin
  result:=bottom-top;
end;
 
procedure TRect.setWidth(AValue: Longint);
begin
  right:=left+avalue;
end;
 
 
procedure TRect.setHeight(AValue: Longint);
begin
  bottom:=top+avalue;
end;

dans Lazarus\fpcsrc\rtl\objpas\classes\classesh.inc

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
 
function Rect(ALeft, ATop, ARight, ABottom: Integer): TRect;
function Bounds(ALeft, ATop, AWidth, AHeight: Integer): TRect;
 
function Rect(ALeft, ATop, ARight, ABottom: Integer): TRect;
 
begin
  with Result do
  begin
    Left := ALeft;
    Top := ATop;
    Right := ARight;
    Bottom := ABottom;
  end;
end;
 
 
function Bounds(ALeft, ATop, AWidth, AHeight: Integer): TRect;
 
begin
  with Result do
  begin
    Left := ALeft;
    Top := ATop;
    Right := ALeft + AWidth;
    Bottom :=  ATop + AHeight;
  end;
end;

Resultats :

Les dimensions maximales de ma surface de travail : W = 10, H=10
X1 := 1 et Y1 := 1

Rect(x1,y1,w,h) Ici W et H nes sont plus des coordonnées mais des vecteurs décrivant une direction et une longueur

Ecriture :

right := 1 + 10 = 11
bottom := 1 + 10 = 11

Lecture :
getHeight := 11 - 1 = 10
getWidth := 11 - 1 = 10

Normalement
Cela devrait être, par logique

Lecture :
getHeight := = 10
getWidth := = 10
Bottom := 10
Right := 10

On compte de 1 à 10 et la largeur ou la hauteur est de 10

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
 
{------------------------------------------------------------------------------
  procedure TCanvas.FillRect(X1,Y1,X2,Y2 : Integer);
 ------------------------------------------------------------------------------}
procedure TCanvas.FillRect(X1,Y1,X2,Y2 : Integer);
begin
  FillRect(Rect(X1,Y1,X2,Y2));
end;

Si X1,Y1 = (1,1) et si X2 = W ,Y2 = H = (4,1)

alors
right := 1 + 4 = 5 = WIDTH selon Mcrosoft
bottom := 1 + 1 = 2 = HEIGHT selon Mcrosoft

Donc si je décide d'utiliser les spécifications de Microsoft :

Nombre de pixel de l'image Bottom*Right = 5*2 = 10 ouch mais mon image doit faire 4x1 non ???

La façon de calculer la largeur et la hauteur est improductive et erronée car le minimum de X1 et Y1 ce n'est pas 1 mais 0 (c'est comme ça, je ne l'ai pas inventé)

T'as essayé BrushColor := Canvas.Pixels[4,1] ou BottomRightColor := Canvas.Pixels[ARect.Right,ARect.Bottom] ?
nb ARect := Rect(0,0,w,h);

Si X1,Y1 = (0,0) et si (X2,Y2) = 4,1

alors
right := 0 + 4 = 4
bottom := 0 + 1 = 1

Nombre de pixel de l'image 4*1 = 4

Le problème c'est que dans le contexte du graphisme cela peux engendrer énormément d'erreurs d'affichage. Right et Bottom ne sont pas la pour décrire une largeur et une hauteur à la base

Essayes ça FCLImageTest.zip et dis moi ce que tu en penses regardes bien à la loupe les dernière lignes du rectangle

Une explication à l'utilisation du Rect et TRect ici ? On voit bien lea différence suivant comment nous décidons de nous servir du TRect

Voila comment je me visualise un bitmap en mémoire avec les différentes conventions:

Chaque case blanche correspond à un pixel. L'adresse d'un tampon en mémoire commence à zero.
Les dimension du bitmap sont de 20x20 donc occupation en mémoire 400 pixels



Pour utiliser Width et Height avec un TRect il aurais fallue mieux faire :

1)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
 
function TRect.getWidth: Longint;
begin
  result:=(right-left)+1;
end;
 
function TRect.getHeight: Longint;
begin
  result:= (bottom-top)+1;
end;
 
procedure TRect.setWidth(AValue: Longint);
begin
  right:= (left+avalue)-1;
end;
 
procedure TRect.setHeight(AValue: Longint);
begin
  bottom:=(top+avalue-1);
end; 
 
function Bounds(ALeft, ATop, AWidth, AHeight: Integer): TRect;
begin
  with Result do
  begin
    Left := ALeft;
    Top := ATop;
	Width := AWidth;
	Height := AHeight;
    // Right := (ALeft + AWidth) - 1;
    // Bottom := (ATop + AHeight) -1;
  end;
end;

2)Ou à mon sens il aurait été souhaitable de créer un type pour cette spécificité genre un truc tout simple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
Type
  TBounds = packed record
    Top : Integer;
	Left : Integer;
	Width : Integer;
	Height : Integer;
  end;

et fonction similaire a l'original "Bounds" mais corrigé. Dans ton exemple Bounds devrait être la fonction que tu devrais utilisé au-lieu de Rect par la spécification Bounds préférable dans ce cas.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
 
function Bounds(ALeft, ATop, AWidth, AHeight: Integer): TBounds;
begin
  with Result do
  begin
    Left := ALeft;
    Top := ATop;
	Width := AWidth;
	Height := AHeight;
    // Right := (ALeft + AWidth) - 1;
    // Bottom := (ATop + AHeight) -1;
  end;
end;
 
function BoundsRect(ALeft, ATop, AWidth, AHeight: Integer): TRect;
begin
  with Result do
  begin
    Left := ALeft;
    Top := ATop;
    Right := (ALeft + AWidth) - 1;
    Bottom := (ATop + AHeight) -1;
  end;
end;

Ca existe déja ?

L'utilisation de TBounds éviterai beaucoup de confusion et éviterai de passer des heures pour enfin trouver le fautif d'une erreur d'affichage, ou problème d'accès aux données du bitmap en mémoire. Maudit TRect

Bref, après tout ça, dur dur de s'y retrouver, nous avons tous les deux raison sur l'utilisation que peut-être faite du TRect. En gros on choisi nous même de comment il fonctionne. (X, Y, Width, Height) ou (X1, Y1, X2, Y2)
Donc attention à l'utilisation du TRect avec des "Width" et "Height" suivant les cas et utilisons Bounds au lieu de rect qui est plus approprié dans le cas d'une utilisation "alla" windows

C'est même d'ailleurs assez drôle de s'appercevoir comment il est rapide de passer d'un forme à l'autre de TRect de manière instinctive et "sournoise" sans que l'on s'en rendre compte.
Notre cerveau est dur en affaire.

Ce fut long, mais productif pour moi ce petit "time of" TRect

[BeanzMaster]

Après tout ça revenons donc au sujet qui nous intéresse, qu'en penses tu ?

La taille maximale d'un bitmap semble être limitée par la taille de la mémoire physique (ram) disponible sur nos pc. Au-delà de cette limite il faut faire autrement ("FileMapping" + ????)

J'ai créé avec IrfanView une image de 64000x16000x32 = 4Go et une un peu plus grande de 64000x20000x32 = environ 5,1 Go = 1 280 000 000 pixels = 5 120 000 000 d'octets soit 40 960 000 000 de bits

Avec une application test identique à celle de BGRABitmap dans un des messages précédent. Sous Windows. Mais utilisant ma solution

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
 
Unit Unit1;
 
{$mode objfpc}{$H+}
 
Interface
 
Uses
  Classes, SysUtils, FileUtil, Forms, Controls, Graphics, Dialogs, StdCtrls, ExtCtrls,
  BZGraphic, BZBitmap, BZBitmapIO;
 
Type
 
  { TForm1 }
 
  TForm1 = Class(TForm)
    Button1: TButton;
    OPD: TOpenDialog;
    pnlView: TPanel;
    Procedure Button1Click(Sender: TObject);
    Procedure FormCreate(Sender: TObject);
    Procedure FormDestroy(Sender: TObject);
    Procedure FormPaint(Sender: TObject);
  private
 
  public
    Bmp  : TBZBitmap;
    isLoaded : Boolean;
  End;
 
Var
  Form1: TForm1;
 
Implementation
 
{$R *.lfm}
 
{ TForm1 }
 
Procedure TForm1.FormCreate(Sender: TObject);
Begin
  isLoaded := False;
  Bmp := TBZBitmap.Create;
end;
 
Procedure TForm1.Button1Click(Sender: TObject);
Var
  w,h : integer;
Begin
  if OPD.Execute then
  begin
    w := pnlView.ClientRect.Right;
    h := pnlView.ClientRect.Bottom;
    Screen.Cursor := crHourGlass;
    Bmp.LoadFromFile(OPD.FileName);
    Bmp.Transformation.Stretch(w,h,true);
    isLoaded := True;
    Screen.Cursor := crDefault;
    Invalidate;
  End;
end;
 
Procedure TForm1.FormDestroy(Sender: TObject);
Begin
  FreeAndNil(Bmp)
end;
 
Procedure TForm1.FormPaint(Sender: TObject);
Begin
  if IsLoaded then Bmp.DrawToCanvas(pnlView.Canvas, pnlView.ClientRect,True,False); // Satané TRect.i Il est ou ClientBounds ???? mdr Microsoft ou pas Microsoft ?
end;
 
End.

L'image est redimensionnée pour qu'elle s'adapte à la fenêtre (un bitmap temporaire est donc utilisé)

Avec l'image 64000x20000x32 j'ai 2 Bitmaps actifs en même temps à un moment pour une taille de environ 10,240 Go en mémoire au minimum

Sous Windows

Mémoire libre au début du test environ 12,6Go
A la fin de la lecture du fichier 7,2 Go Libre
Mise en cache de 5.2 Go
Au redimensionnement 3.6 Go Libre

L'image est chargée et l'affichage est correcte.

Par contre, avec mon outils toujours sous windows j'ai une erreur lors de l'affichage avec ce même fichier. Plus assez de mémoire pour le redimensionnement.



Sous Linux par contre par de problème. La différence de mémoire libre y est surement pour beaucoup, la mémoire physique est quasiment saturée il ne reste plus que 1Go( ce qui n'est rien de nos jour) plus beaucoup ( lors du 150 mo environ à la fin du redimensionnement et du transfert de l'image vers l'écran.



Il faut donc penser également aux ressources de l'application elle même, prend en mémoire ( a quel moment ?), plus tout le reste de "caché". Il faut donc se garder une marge de manoeuvre

EDIT ha oui il y a bug avec le TShellListView lors du clique sur ce fichier qui m'affiche la première image de la liste

J'ai voulu essayé 64000x24000 mais irfanView a planté. Pour mon outils en l'état, je considère que la limite est atteinte avec une image de 64000x16000 soit 4Go peu importe les dimensions 128000x8000 ou n'importe quel autres tant que l'allocation mémoire ne dépasse pas ces 4Go

Question, comment allouer un espace mémoire qui utiliserait la "mémoire Swap" pour dépasser la limite de la mémoire physique libre ?

C'est la que tu t'imagines te rendre compte que Gimp, sont code pour gérer la mémoire doit-être élaboré.

Entre le "FileMapping" qui il me semble a des limitations, mais je ne me souviens plus. et dont la gestion est un peu différente entre windows et unix. Ce n'est pas un insurmontable.
Après que faire ? La lecture d'une seule région des données en temps réel dans le fichier "mappé" ?
Création de plusieurs fichiers mappés ?

Bref la liste peut devenir très longue et il y a de quoi rêver.

[foetus]

Après que faire ? La lecture d'une seule région des données en temps réel dans le fichier "mappé" ?
Création de plusieurs fichiers mappés ?

Bref la liste peut devenir très longue et il y a de quoi rêver.

Ce sont des techniques qui existent depuis longtemps dans le jeux sous le terme générique "texture streaming".

Par exemple, id dans leurs moteurs id Tech utilise des méga-textures, qui permettent de texturer une carte (ou une très grosse partie) en 1 seule fois ... et c'est pour cette raison que les bâtiments ne sont pas destructibles

En gros, ton image-texture est découpée en morceaux et chaque morceaux sont des mipmaps (cette partie est en plusieurs résolutions, de faible à [très] grande)
Évidement il faut soupçonner que la mémoire vidéo est également utilisée, que des threads helpers doivent travailler en tâche de fond pour charger la bonne mipmap et son alentour.

Et donc, le but du jeu c'est d'afficher la (les) bonne(s) mipmap(s), en entier ou en partie, en fonction du zoom et prévoir tout déplacement de l'image

[BeanzMaster]

Ce sont des techniques qui existent depuis longtemps dans le jeux sous le terme générique "texture streaming".

Par exemple, id dans leurs moteurs id Tech utilise des méga-textures, qui permettent de texturer une carte (ou une très grosse partie) en 1 seule fois ... et c'est pour cette raison que les bâtiments ne sont pas destructibles

En gros, ton image-texture est découpée en morceaux et chaque morceaux sont des mipmaps (cette partie est en plusieurs résolutions, de faible à [très] grande)
Évidement il faut soupçonner que la mémoire vidéo est également utilisée, que des threads helpers doivent travailler en tâche de fond pour charger la bonne mipmap et son alentour.

Et donc, le but du jeu c'est d'afficher la (les) bonne(s) mipmap(s), en entier ou en partie, en fonction du zoom et prévoir tout déplacement de l'image

Je vois très bien de quoi tu veux parler. Mais ici cela ne changera rien même si je divise mon image par 4 ou en 8 (par rapport au nombre de thread disponibles, pour accélérer les traitements) mas limite est toujours la mémoire physique RAM Libre. Ici je n'utilise pas les capacités des cartes graphiques. Les échanges seront toujours Disque --> RAM --> Carte graphique.

Le filemapping sous windows, j'ai déja mis en place et est bénéfique pour la lecture de gros fichiers. La question que je me pose c'est ou le filemapping alloue ces tampons ? Si c'est dans la mémoire physique cela risque de faire chuter le maximum de Go possible d'afficher

Le truc c'est comment fait-on pour allouer un bloc mémoire dans le swap si la mémoire physique libre est insuffisante ?

Ensuite seulement la technique du "texture streaming" ou autres pourront être mis en place.

[Jipété]

Ola !

Le truc c'est comment fait-on pour allouer un bloc mémoire dans le swap si la mémoire physique libre est insuffisante ?

Lors de l'exécution des tests que j'ai publiés, j'ai pu constater que, navigateur ouvert mais réduit en barre de tâches, celui-ci avait été "évacué" dans le swap simplement lors de la création de grands fichiers.
Aucune action directe de ma part dans ce sens, donc.
M'en suis rendu compte car à la fermeture du prog de test, quand j'ai "remonté" le navigateur de la bdt, les bordures de sa fenêtre ont très vite été présentes mais pas son espace d'affichage qui était désespérément vide et blanc et il m'a fallu attendre pendant que j'entendais le disque gratter à fond.

Alors comment trouver l'info ? J'ai peur qu'une recherche avec des mots genre FreePascal swap ne remonte des pages où les gens se plaignent, ou alors sur la manière de le gérer (genre swapon et swapoff sous Linux), mais comment dire à l'OS "dégage-moi ce bout j'ai besoin de place" ?
Tout ce que je vois c'est contourner le problème : pour dégager ce bout qui ne me sert pas pour l'instant, je le mets dans un fichier temporaire et une fois celui-ci écrit sur le disque je peux libérer ses ressources.

Remarks
...
For example, when RECT is passed to the FillRect function, the rectangle is filled up to, but not including, the right column and bottom row of pixels.

...
Par exemple, lorsque RECT est passé à la fonction FillRect, le rectangle est rempli jusqu'à la colonne de droite et la rangée inférieure de pixels.

Juste oublié, dans la traduc' française, ces trois mots qui me semblent cruciaux, justement : "but not including" !
La traduc' devient donc

Par exemple, lorsque RECT est passé à la fonction FillRect, le rectangle est rempli jusqu'à la colonne de droite et la rangée inférieure de pixels mais sans les inclure.
["les" faisant référence à la colonne et la rangée, et pas les pixels -- c'est plus clair in english -- ou alors le dire autrement (mais un poil plus lourd) : mais sans qu'elles soient incluses]

Effectivement, tu nous as concocté un sacré pavé, tout à ton honneur, dans lequel tu as même inclus des liens vers des pages qui doivent contenir des liens vers des pages qui doivent... bref, y en a pour 6 mois pour tout assimiler, or j'ai du Scanline sur le gaz (un poème, cette engeance, en mode multi-plateforme à gérer à coups de {$IFDEF MOTCLEF}...)

Bon samedi,

[mm_71]

Pour tes problèmes de mémoire tu peux toujours essayer:
http://wiki.tuxunix.com/index.php/Li...ire_sous_Linux
https://www.vincentliefooghe.net/con...ram-et-du-swap
Pour vider les zones mémoire réservées mais inutilisées.

[foetus]

Qui ça, "on" ?
Moi je ne fais rien du tout, je me contente de trafiquer les couleurs des pixels.

On , c'est le couple processeur - contrôleur mémoire (qui est dans le processeur)

Le processeur, s'il ne trouve pas les valeurs dans ces caches ou s'il doit faire un accès mémoire, il fait appel au contrôleur mémoire.
Mais si le processeur doit faire appel au contrôleur mémoire à chaque fois (par exemple lors d'un parcours d'un tableau), cela va plomber les performances

Et donc, le contrôleur mémoire va plutôt retourner "un morceau" de mémoire. Après cela va dépendre des systèmes d'exploitation, des situations, ...

Au final, j'ai peur qu'il n'y ait pas de réponse définitive aux limites de tailles et donc, comment prévenir l'utilisateur que ça va partir en vrille ?
Ou pas.
Aléatoirement...

Avec des langages comme le C et le C++, je dirais qu'il faut gérer au moins les allocations qui retournent NULL ou le retour des exceptions out of memory.
Mais par contre, ton application doit être solide pour détecter les erreurs, nettoyer le mémoire inutile, et afficher un petit message et ... ne pas planter.

Après, il ne faut pas que pour ce genre d'erreurs, chaque surcouche, chaque bibliothèque apporte sa propre touche, et que ce soit un barnum à gérer toutes les exceptions, toutes les allocations foirées, tous "les trucs" spécifiques à surcharger ...

Ensuite seulement la technique du "texture streaming" ou autres pourront être mis en place.

Je dirais que je vois la chose différemment Mettre en place des techniques comme "texture streaming" ou autres (plus légères, plus adaptées) pour pouvoir maximiser l'utilisation mémoire de son application.
Et donc :

• avec un helper qui permet de détecter la configuration matérielle (quantité mémoire, capacité 3D, ...) et ainsi contraindre ton application à un maximum mémoire. Après si la cible n'a pas beaucoup de mémoire (< 2 Go) là on ne peut plus rien faire.
• ne pas dépendre des systèmes d'exploitation sur la gestion du swap, des limites de l'allocation mémoire, ... Toutes les questions que tu te poses

[anapurna]

salut

tu peut aussi mettre en place un système de buffer pour la lecture de ton stream ce qui ne t'oblige pas à charger
le fichier en entier
mais après cela dépend de ce que tu fait avec ton buffer
regarde un exemple de type de stream pouvant etre exploité ici

[BeanzMaster]

Salut

salut

tu peut aussi mettre en place un système de buffer pour la lecture de ton stream ce qui ne t'oblige pas à charger
le fichier en entier
mais après cela dépend de ce que tu fait avec ton buffer
regarde un exemple de type de stream pouvant etre exploité ici

C'est exactement ce que fait ma classe TBZBufferStream (l'unité complète est au début de la discussion) sauf que je ne me suis pas limité à seulement TFileStream. La lecture n'est pas vraiment un problème. L'image est forcément plus grande que notre écran, il faut pouvoir se déplacé (scrolling) . En premier la totalité des données (décompressées si besoin : Jpeg, png ect...) serait mise en mémoire via le "FileMapping" pour exploiter la mémoire swap. Ensuite c'est tout le système du Bitmap qu'il faut modifié. Il faudrait avoir un système de double tampon voir plus (4 à mon avis) ou plus. 1 pour l'affichage et les autres de de même taille, que l'affichage je dirai. Ces tampons seraient la uniquement pour le chargement des données. Ce qui inclurait également la mise en place de Threads pour faire les chargements en tache de fond. Le tampon d'affichage lui ce déplacerai en fonctions dans un ou plusieurs de ces tampons temporaires et arriver à une certaine position un ou plusieurs tampon devraient être chargé. Cela reste complexe. Je vais déja inclure la possibilité de faire du "FileMapping" pour la lecture, ça sera déjà pas mal. Et on verra pour la suite. Je pense pas qu'il y existe beaucoup de personne qui exploite des images de plusieurs Go.

[BeanzMaster]

Je viens juste d'aller chez les voisin c'est drôle des fois quand même et voici une discussion sur le thème de la quantité de ram que l'on peux alloué en date d'aujourd'hui

Reponse de Taddhy :

Re: heap size over available RAM
« Reply #1 on: Today at 09:02:08 am »
Well, the best solution is to have 64G of memory. Anything other will be slower.
The default FPC memory manager looks at true available memory, not at swap space, so that won't work properly.
But you can write a custom memory manager that uses a (partial or wholly) heap on disk. That will be slower.
Such variables are better replaced with a (buffered) filestream if cost is an issue.

D'ailleurs il me semble que FastMM pour Delphi gère la mémoire swap. Hum ça serait bien d'avoir un tel manageur de mémoire pour FPC également

[mm_71]

Je pense pas qu'il y existe beaucoup de personne qui exploite des images de plusieurs Go.

En dehors de l'impression de posters grand format ou d'affiches je ne pense pas non plus.

[anapurna]

salut

tu veut faire un backend ou backbuffer comme graphics32 ?

[BeanzMaster]

salut

tu veut faire un backend ou backbuffer comme graphics32 ?

Je viens de jeter un oeil vite fait à Graphics32, si tu fais allusion à TMMFBackend = class(TMemoryBackend) dans l'unité GR32_Backends_Generic alors oui un truc dans le genre, c'est ce que j'ai plus ou moins en tête.
Je ne sais même pas si graphic32 l'utilise dans les exemples. A tester

[anapurna]

salut

a priori il s'en sert dans TCustomBitmap32, TCustomPaintBox32
qui est l'ancetre de TPaintBox32, TCustomImage32

On peut penser qu'il s'en sert sans que tu t'en aperçoit

[BeanzMaster]

Hello j'ai regardé plus profondément pour comprendre, le système mis en place n'est pas bête du tout. Mais je le trouve un peu trop "rigide". Après vérification l'auteur ne se sert pas des classes de backend utilisant le "FileMapping" par défaut. Il faut modifié le "backend" à la main. Ensuite j'ai un doute sur son utilisation des api de filemapping sous windows pour accéder aux données. Il faut que je retrouve une ancienne source pour vérifier.