[FMX] Unerklärliche EBitmapSizeTooBig-Exception

[DeddyH]

Ich benutze die ksTableView-Komponente (so ähnlich wie TListView, nur mit mehr Möglichkeiten, über GetIt zu beziehen). Unter Android tritt das Phänomen auf, dass in deren EndUpdate-Methode o.a. Exception auftritt. Per Debugger bin ich dann in FMX.Graphics in der Methode TBitmap.SetSize fündig geworden.

Zitat:

Delphi-Quellcode:

procedure TBitmap.SetSize(const AWidth, AHeight: Integer);
var
  SaveBitmapScale: Single;
begin
  if (FImage.FWidth <> AWidth) or (FImage.FHeight <> AHeight) then
  begin
    if (AWidth > CanvasClass.GetAttribute(TCanvasAttribute.MaxBitmapSize)) or
       (AHeight > CanvasClass.GetAttribute(TCanvasAttribute.MaxBitmapSize))
    then
      raise EBitmapSizeTooBig.CreateRes(@SBitmapSizeTooBig);
    ...
  end;
end;

Zum Zeitpunkt der Exception steht AWidth auf 100 und AHeight auf 64. Wenn ich den Code richtig verfolgt habe, gibt CanvasClass.GetAttribute(TCanvasAttribute.MaxBitma pSize) $FFFF zurück, also 65535, das liegt in beiden Fällen weit über den übergebenen Werten, selbst wenn man beide multipliziert. Hat jemand eine Ahnung, weshalb der Vergleich nicht stimmt?

[edit] Nachtrag: ich habe die FMX.Graphics.pas mal ins Projektverzeichnis kopiert und geringfügig geändert. Dabei ist herausgekommen, dass mitnichten $FFFF zurückkommt, sondern 0. Es wird immer wilder. [/edit]

[Uwe Raabe]

Kannst du feststellen, was zu dem Zeitpunkt genau in CanvasClass drin steht? Ich vermute mal TCanvasGpu.

Eventuell wird für die Bitmap kein sinnvoller Kontext gesetzt. Der Default-Kontext unter Android (GLES) hat womöglich keinen brauchbaren Wert für GL_MAX_TEXTURE_SIZE. Das wird nämlich für MaxBitmapSize zurückgegeben.

Aber selbst mit einem gültigen Kontext kann es dir passieren, daß hier der für Android vorgegebene Minimalwert von 64 zurückgegeben wird. Da wäre dann die 100 wirklich schon zu groß.

[DeddyH]

Kleines Update: das tritt nur auf, wenn ich den Scanner (ZXing) benutze. In dem Fall ist MaxBitmapSize dann 0. Gebe ich den Wert des Barcodes o.ä. händisch ein, ist alles in Butter. Könnte es sich um ein Speicherproblem handeln?

[DeddyH]

Es scheint sich um ein Timing-Problem zu handeln. Zum Zeitpunkt des Fehlers belegt ZXing anscheinend noch alle Ressourcen. Vorläufig behelfe ich mir mit einem Timer, da ich nicht weiß, wie ich mitbekommen kann, wann diese Ressourcen wieder freigegeben wurden, ein entsprechendes Event scheint es nicht zu geben. Falls da jemand einen Tipp hat, bin ich ihm sehr dankbar, aber so geht es auch vorerst. Nicht schön, aber selten :mrgreen: