Discussion :

[der§en]

Bonjour,

Voici l'original :

Et sa version sous Lazarus :

Petit défi du jour, convertir les sources Firemonkey du programme DWS TeraPixel Mandelbrot en source FPC / Lazarus.

Ce programme n'utilise que le framework FMX, aucun composant spécifique sous Delphi ; par contre, ma version a besoin sous Lazarus du paquet INDY 10 et de BGRABitmap pour compiler.

J'ai une première version fonctionnelle, mais du fait des différences entre l’architecture FMX et LCL, j'ai des petits soucis a l’exécution.

Mon premier problème est quand je change le niveau de zoom, j'ai un effacement de l'image indésirable, il faudrait que je trouve le moyen de bloquer le rafraichissement soit du canvas d'un panel soit celui d'un BGRABitmap !

Mon second souci est lié à Indy, si je suis en cours de chargement de tuile depuis le site et que je ferme le programme, j'ai un beau plantage du programme lié à Indy. N'étant pas un expert Indy, je n'ai pas trouvé comment le corriger !

Ensuite, il restera à optimiser le programme car il y a une grosse différence de performances entre la version Delphi et la version Lazarus à la défaveur de ce dernier

Si vous avez des idées ou des suggestions, voire des corrections, je suis preneur

Dergen.

[Roland Chastain]

Intéressant !

Je crois qu'il manque le fichier formexplorer.lfm dans le ZIP que tu as posté.

[der§en]

Oups, voici le zip complet.

Je me suis lancé ce défi, car le programme utiliser les génériques et les méthodes anonymes, que je pratique peu.

Par contre il y a visiblement une grosse différence dans le fonctionnement des threads ou du composant iDHTTP entre Delphi et Lazarus, en effet, si on zoom trop vite, le programme plante.

Voici la version Lazarus aux même coordonnées que l'original :

[der§en]

J'ai résolu, le problème du rafraîchissement de l'image.

Par contre, je sèche sur le problème qui fait planter le programme, si je zoom 2 fois de suite sans attendre la fin du chargement des tuiles.

Si quelqu'un avait une idée de ce qui pourrait coincer, cela m'aiderait bien...

[BeanzMaster]

Salut,

sans voir le code, il faudrait surement que tu annules le téléchargement des tuiles si celles-ci sont en cours, pour recharger les nouvelles en fonction de la valeur du nouveau zoom.
Le mieux serait surement de "threader" les téléchargements ou de placer un drapeau pour savoir si les tuiles sont totalement chargées ou pas, qu'il suffira de tester.
Ou de simplement inhiber le zoom tant que le téléchargement et l'affichage n'est pas fini.

[der§en]

Si tu as le temps de regarder les sources que j’ai posté ici, tu verras que c’est comme cela que le programme fonctionne.

Au niveau de la gestion des threads, il dois y avoir une différences entre Delphi et FPC que je ne maîtrise pas, qui provoque le plantage sous Lazarus.

[BeanzMaster]

Si tu as le temps de regarder les sources que j’ai posté ici, tu verras que c’est comme cela que le programme fonctionne.

Au niveau de la gestion des threads, il dois y avoir une différences entre Delphi et FPC que je ne maîtrise pas, qui provoque le plantage sous Lazarus.

Hello, hum pas facile de trouver. De plus je ne peux pas tester, il faut que je mette à jour ma version de Lazarus.

Il y a une ligne qui me titille dans DownloadThread while AnyThreadsRunning do FAddedEvent.SetEvent; je comprend pas à quoi sert SetEvent.

Je n'ai pas trouvé ou est-ce que tu arrêtes et purges ton downloadThread avant un zoom.

Sur quelle ligne est levée ton exception ?

[der§en]

Je vais tracer le prog, et je te dirais, ce que je trouve.

[Andnotor]

N'ayant pas Lazarus, je réagis juste sur le code

Cet event ne sert strictement à rien actuellement. Il serait censé prévenir qu'une nouvelle tuile est demandée mais puisqu'il est signalé avant même le démarrage des tâches (TTileDownloader.AddTile) et qu'il n'est jamais reseté, c'est comme s'il n'existait pas. Les tâches secondaires tournent plein pot même lorsqu'il n'y a rien à faire.
Il devrait au minimum être reseté dans TTileDownloader.PopTile lorsque la liste est vide mais dans l'idéal, chaque DownloadThread devrait avoir son propre event de démarrage.

Mais le gros problème est que tout est interdépendant et il est obligé d'introduire des rustines (avec plus ou moins de bonheur) pour synchroniser tout cela. Par exemple dans TTileDownloader.AnyThreadHoldingTileRef, Thread.HasTileReference ne peut garantir qu'aucune tuile est utilisée puisque ça dépend de la ligne en cours dans TDownloadThread.Execute.

C'est par là que je commencerais les recherches ; contrôler les synchros.

[circular17]

Bonjour, voilà un projet très coloré !

Je suggère de précalculer le tableau de couleur :

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
const
  ColorMaxValue = 200;
 
function ComputeColorForValue(const Value: Integer): TBGRAPixel;
begin
  // Simple hue-only, using Value in range 0-MaxValue, wrapping.
  // Hue must be in range 0-1, so wrap to MaxValue and then shrink 0-1.
  Result := ColorToBGRA(HSVtoRGB((Value mod ColorMaxValue) / ColorMaxValue, 1.0, 1.0));
end;
 
var
  ColorTab: array[0..199] of TBGRAPixel;
 
function ColorForValue(const Value: Integer): TBGRAPixel;
begin
  result := ColorTab[Value mod ColorMaxValue];
end;
 
var i: integer;
 
initialization
 
  for i := 0 to ColorMaxValue-1 do
    ColorTab[i] := ComputeColorForValue(i);
 
end.

Au moment de la copie vers l'image, vous pouvez optimiser comme cela :

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
var
  ...
  PValue: PInteger;
begin
  ...
  else if (Length(FData) = TILE_WIDTH * TILE_HEIGHT) then
  begin
    // Array has elements for every pixel
    for LY := 0 to TILE_HEIGHT-1 do
    begin
      Row :=  FBitmap.Scanline[LY];
      PValue := @FData[TILE_WIDTH * LY];
      for LX := 0 to TILE_WIDTH - 1 do
      begin
        Row^ := ColorForValue(PValue^);
        Inc(PValue);
        Inc(Row);
      end;
    end;

Cela est peut-être anecdotique au niveau du temps, cela dit.