4. Sinnloser 'Andromeda und volkard haben Langeweile' Thread

Sinnloser 'Andromeda und volkard haben Langeweile' Thread


  • .

    0
  • A

    volkard schrieb:

    Er braucht im Prinzip einen Roboter, der auf dem PC eine von ihm per Programm angegebene Webseite aufmacht und dann mit der Kamera das Monitorbild vom Browser knipst und dann das geknipste Bild hochlädt. Wenns geht ohne Bastelaufwand mit Lego.

    Aber nur über irgendeine krasse Enterprise-RESTful API die QR-Codes verwendet.
    Darunter geht gar nix. Gigahertz und Gigabytes brauchen schließlich eine Berechtigung. 🙂

    0
  • E

    Das mit base64 codiertem HTML ist Quatsch. Kommt höchstens mal ganz selten in äußerst zweifelhaftem code vor, und dann ist es Javascript und nicht HTML.
    Das mag vielleicht mit favicons benutzt werden, aber wenn schon, drücke dich korrekt und exakt aus, Andromeda.

    0
  • V

    hustbaer schrieb:

    Du befindest es jetzt also schon für nötig mich in meinen eigenen Threads gezielt zu verarschen?
    Echt jetzt?
    Was ist eigentlich kaputt bei dir?

    Du best sehr erwachsen.

    volkard schrieb:

    Nein. Es geht nicht um Webseiten. Es geht um die Erstellung von "hübschen Bildern" mit bestimmten Daten drinnen.

    Und wo ist da der wichtige Unterschied?

    0
  • A

    EOP schrieb:

    Das mit base64 codiertem HTML ist Quatsch.

    Gar nicht. Siehe hier: https://www.hackerboard.de/-web-design-und-webbasierte-sprachen/39760-bilder-binaer-im-html-code.html

    0
  • G

    @Andromeda, @volkard
    Reißt euch zusammen und postet nicht so einen Quatsch.

    0
  • A

    GPC schrieb:

    @Andromeda, @volkard
    Reißt euch zusammen und postet nicht so einen Quatsch.

    Husti soll sich mal genauer ausdrücken.
    Will er vielleicht eine Webseite in eine Bitmap rendern?

    0
  • N

    hustbaer schrieb:

    Ich muss in einem Web-Service ein paar Bitmaps mit dynamischem Inhalt erzeugen.

    Geil.
    Und zur Vereinfachung erstmal Forenthreads mit dynamischem Inhalt erzeugen..

    0
  • A

    nachtfeuer schrieb:

    hustbaer schrieb:

    Ich muss in einem Web-Service ein paar Bitmaps mit dynamischem Inhalt erzeugen.

    Geil.
    Und zur Vereinfachung erstmal Forenthreads mit dynamischem Inhalt erzeugen..

    "Bitmaps mit dynamischem Inhalt" können eigentlich nur GIFs sein. Wobei bewegt ja nicht das Gleiche wie dynamisch ist.

    0
  • A

    hustbaer schrieb:

    Dummerweise ist na bloss der CSS-Support reichlich unterirdisch. Es funktioniert nichtmal das Ausrichten von Text an der Baseline des Parent Elements (" vertical-align: baseline; ", was sogar Default ist - bzw. halt sein sollte).

    Wenn dir standardkonformes Rendering wichtig ist, wirst du wohl kaum um einen richtigen Renderer herumkommen.

    Bei Trident (MSHtml.dll) bin ich nicht ganz sicher, wie gut sich das mit einem Service verträgt. Man findet zwar allerorten Beispiele über das Rendern mit IHTMLElementRender::DrawToDC(), aber laut MSDN ist das schon seit langem deprecated.

    Das Chromium Embedded Framework scheint diesen Anwendungsfall aber ausdrücklich zu unterstützen, cf. https://bitbucket.org/chromiumembedded/cef/wiki/GeneralUsage#markdown-header-off-screen-rendering. Vielleicht solltest du dir das anschauen.

    0

  • nachtfeuer schrieb:

    hustbaer schrieb:

    Ich muss in einem Web-Service ein paar Bitmaps mit dynamischem Inhalt erzeugen.

    Geil.
    Und zur Vereinfachung erstmal Forenthreads mit dynamischem Inhalt erzeugen..

    Wenn du mir etwas mitteilen willst, dann bitte so dass man auch verstehen kann was gemeint ist.

    0

  • @audacia
    Hab ich mir schon angesehen.
    Kommt nicht wirklich in Frage.
    Zu viel Overhead. Einerseits runtime (viel zu langsam - das Erzeugen eines neuen Browser-Objekts haut ordentlich rein) und andrerseits auch bei der Implementierung bzw. beim Deployment (die ganzen Dependencies).

    0
  • A

    hustbaer schrieb:

    Zu viel Overhead. Einerseits runtime (viel zu langsam - das Erzeugen eines neuen Browser-Objekts haut ordentlich rein)

    Gut, aber dann erzeugst du das halt nur einmal und recyclest es. Sehe ich jetzt kein Problem drin.

    hustbaer schrieb:

    und andrerseits auch bei der Implementierung bzw. beim Deployment (die ganzen Dependencies)

    Ja, das ist schon mit Kanonen auf Spatzen. (Lästigerweise kommt es gerade in Mode, Desktopanwendungen mit Angular oder dergleichen zu schreiben und dann immer mitsamt Browser auszuliefern.)

    Ich nehme an, eine Trident-basierte Lösung wäre dir auch nicht recht? Dann vielleicht litehtml zusammen mit dem (Cairo-)Graphikbackend aus litebrowser?

    Edit: Ich sehe gerade, daß du litebrowser gar nicht brauchst, weil in litehtml schon Renderer für Cairo, GDI und GDI+ enthalten sind.

    0

  • audacia schrieb:

    Gut, aber dann erzeugst du das halt nur einmal und recyclest es. Sehe ich jetzt kein Problem drin.

    Ich vermeide statische/globale Dinge gerne wenn möglich. Generell, und nochmal ganz speziell bei Services. Was wenn sich das Teil nach 10000 Requests weghängt? Oder leakt oder...

    audacia schrieb:

    Ich nehme an, eine Trident-basierte Lösung wäre dir auch nicht recht?

    Die Ansprüche an die Layout-Engine sind nicht so hoch - mehr als "so gut wie nix" wäre halt schön. Da reicht das was Trident kann locker.

    Nur will ich nicht wirklich eine komplette Browser-Engine (inklusive JS-Interpreter etc.) hochziehen, wenn ich eigentlich nur den Layout/Rendering Teil für HTML+CSS brauche und sonst nix.

    Kann man den reinen Rendering-Teil von Trident "so" ansprechen? Und kann man das dann auch aus nem Service machen welches von IIS gehostet wird?

    audacia schrieb:

    Dann vielleicht litehtml zusammen mit dem (Cairo-)Graphikbackend aus litebrowser?

    Gibt's dafür fertige .NET Bindings (oder gleich nen fertigen OO Wrapper)?
    Wenn nicht, dann steht der Aufwand wohl nicht dafür.

    Das ganze bewegt sich in einer Grössenordnung wo ich schätze dass ich den nötigen Rendering-Code wahrscheinlich in nem Tag oder so mit GDI+ ( System.Drawing ) implementiert bekomme. Der Nachteil dieser Lösung ist dann bloss dass Änderungen am Layout dann viel mühsamer werden, als wenn das ganze HTML ist das aus nem Razor-Template generiert wird.
    Und Änderungen werden sicher noch ein paar kommen. Zwar hoffentlich nicht viele, und hoffentlich keine groben, aber mit 2-3 "mittleren" Änderungen rechne ich auf jeden Fall.

    0
  • A

    hustbaer schrieb:

    Ich vermeide statische/globale Dinge gerne wenn möglich. Generell, und nochmal ganz speziell bei Services. Was wenn sich das Teil nach 10000 Requests weghängt? Oder leakt oder...

    D.h., du verwendest grundsätzlich kein Caching?

    Dein Stabilitätsargument finde ich jedenfalls nicht so überzeugend. Entweder du vertraust dem Code oder du vertraust ihm nicht. Wenn du ihm vertraust, dann erwartest du, daß er bei der ersten (oder einzigen) Verwendung eines Browser-Objekts genau so wenig leckt/hängt wie bei der 100sten. Wenn du ihm nicht vertraust, läßt du ihn sowieso out-of-process laufen und startest ihn neu, wenn er keine Anfragen mehr beantwortet. In beiden Fällen kannst du das Browserobjekt problemlos cachen.

    hustbaer schrieb:

    audacia schrieb:

    Dann vielleicht litehtml zusammen mit dem (Cairo-)Graphikbackend aus litebrowser?

    Gibt's dafür fertige .NET Bindings (oder gleich nen fertigen OO Wrapper)?
    Wenn nicht, dann steht der Aufwand wohl nicht dafür.

    Keine Ahnung. Aber meinst du wirklich, das wird viel aufwendiger als eine einfache C++/CLI-Funktion der Form System::Drawing::Bitmap^ renderHtml(String^ html) ? Über Graphics::FromImage() und Graphics::GetHdc() bekommst du einen HDC , mit dem du dann den GDI- oder GDI+-Renderer aufrufen kannst. Den Code dafür müßtest du dir aus dem litebrowser zusammenkopieren können.

    Wenn du dir nicht mal die Mühe machen willst, dann weiß ich auch nicht 🙂

    0
  • V

    GPC schrieb:

    @Andromeda, @volkard
    Reißt euch zusammen und postet nicht so einen Quatsch.

    Lies aufmerksamer, bevor Du mich zur Ordnung mahnst.

    0

  • volkard, DU SPINNST

    0
Anmelden zum Antworten