Sinnloser 'Andromeda und volkard haben Langeweile' Thread



  • 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.



  • 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 🙂



  • GPC schrieb:

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

    Lies aufmerksamer, bevor Du mich zur Ordnung mahnst.



  • volkard, DU SPINNST


Anmelden zum Antworten