Anzeige:
Seite 4 von 5 ErsteErste ... 2345 LetzteLetzte
Ergebnis 46 bis 60 von 67

Thema: Ueber Kernel auf Grafikkarte zugreifen

  1. #46
    Administrator Avatar von anda_skoa
    Registriert seit
    17.11.2001
    Ort
    Graz, Österreich
    Beiträge
    5.477
    Original geschrieben von axeljaeger
    Da du das, was man mit X11 eben nicht so ohne weiteres machen kann, auf den Screenshots nicht sieht (Controlls, die in dem Fenster halbtransparent über dem Visual in das Fenster fliegen etc.) auf den Screenshots nicht sieht, reichen Screenshots eben nicht aus.
    Nett


    Ob das ganze aus Usabilitygründen fraglich ist, ist auzudiskutieren.
    Bei einem Mediaplayer geht das vielleicht nicht, damit muss man ja im Grunde nicht arbeiten, sondern man kosumiert da.
    Bei einem Programm, das etwas bearbeitet bedeutet jede Änderung der Darstellung einen zusätzlichen Informationstrigger im Gehirn, das will man möglichst auf die wesntlichen Sachen reduzieren.


    Man kann vielleicht runde Fenster machen, aber das geht nicht so gut, wie unter Windows. Ich hab das einmal gemacht und es dann wieder gelassen, weil es zu Flackern und anderen Darstellungsproblemen mit Fenstern kanm, die unter den transparenten Teilen meines Fenster lagen.
    Ok, kannst du besser beurteilen, ich seh da keine Unterschiede.


    Fakt ist:
    "Schöne Grüße aus Oslo?"


    Unter Windows 2000 aufwärts und MacOSX kann man das machen, unter Linux mit X11 im Moment nicht.
    Wieviele X Server Implementationen außer XFree86 hast du dabei getestet, bis du zu diesem allgemeinen Fakt gekommen bist?


    Wenn der einzelne Anwender keine Rechenzeit braucht, kann man das sicher machen. Da ich hauptsächlich programmiere, würde ich jedem Developer lieber einen Rechner mit Prozessor hinstellen. Können ja trotzdem übers Netzwerk gebootet werden. Die Rechenleistung könnte man sich etwa mit dem Teambuilder teilen.
    Hängt natürlich vom Zielpublikum ab, aber die meisten Bürojobs sind nicht rechenaufwendig.
    Wie gesagt, ThinClient Umgebungen boomen im Moment dank Linux.
    Wann immer man etwas über Corporate Desktop liest, im Moment praktisch die Sparte wo große Firmen ordentlich dahinter sind, wirst du auf diese Art von Setup stoßen.


    Da wir ja schon fast am Ende sind, könnte man sich nochmal über die Api von X11 im Gegensatz zu z.B. DirectFB unterhalten.
    Könen wir schon machen, aber ich kann da nicht viel dazu sagen.
    Mir erspart ein hervorragendes Toolkit die Mühe, mich mit irgendwelchen LowLevel Grafik APIs auseinander setzen zu müssen

    Ciao,
    _
    Qt/KDE Entwickler
    Debian Benutzer

  2. #47
    Registrierter Benutzer
    Registriert seit
    16.09.2001
    Beiträge
    1.182

    Hmm

    @anda_skoa: Soweit ich das hier verstanden habe geht es sowieso nur um XFree86. Wer von euch verwendet bitte HumingBird oder was es da sonst noch so gibt...?
    Geändert von Lin728 (19-08-2017 um 21:37 Uhr)

  3. #48
    Administrator Avatar von anda_skoa
    Registriert seit
    17.11.2001
    Ort
    Graz, Österreich
    Beiträge
    5.477

    Re: Hmm

    Original geschrieben von ceisserer
    @anda_skoa: Soweit ich das hier verstanden habe geht es sowieso nur um XFree86. Wer von euch verwendet bitte HumingBird oder was es da sonst noch so gibt...?
    Nein, es geht um X11 ansich im Vergleich zu fest ins System eingebauten Darstellungsmodulen.

    Es gibt haufenweise Leute, die glauben, dass langjährige X Entwickler weniger Ahnung über die Möglichkeiten von X haben, als sie selbst.

    Oder die üblichen "Fakten", dass lokales X irgendwas mit Netzwerk zu tun hätte.

    X11 ist wahrscheinlich die einzige Technologie bei der es in der Linuxbenutzerszene noch mehr FUD gibt als über Qt.

    Ich betreibe hier lediglich FUD Zerstreung, ist fein das mir OSNews gestern mit dem Link zu Keith Packards neuen X Extensions geholfen hat

    Bei X11 ist es ähnlich wie bei Unix: es ist sicher nicht das beste mögliche, aber auf Grund der extrem hohen Flexibilität und Modularität wesentlich vielseitiger als etablierte Konkurrenz.

    Die IMHO einzige ernstzunehmende Alternative ist Fresco, die meisten anderen verzichten in blauäugier Kurzsichtigkeit auf vermeintliche X11-Schwachstellen (Netzwerktransparenz, Portabilität, etc).

    Ciao,
    _
    Qt/KDE Entwickler
    Debian Benutzer

  4. #49
    Registrierter Benutzer Avatar von peschmae
    Registriert seit
    14.03.2002
    Ort
    Schweizland
    Beiträge
    4.549
    ah, Berlin heisst jetzt Fresco

    MfG Peschmä
    The greatest trick the Devil ever pulled was convincing the world he didn't exist. -- The Usual Suspects (1995)
    Hey, I feel their pain. It's irritating as hell when people act like they have rights. The great old one (2006)

  5. #50
    Registrierter Benutzer
    Registriert seit
    08.07.2002
    Beiträge
    719
    Ich hab die Möglichkeiten getestet, die mir Mandrake Linux bietet. Das ist wahrscheinlihc XFree86. Möglicherweise gibt es kommerzielle Systeme, die das anders handhaben, aber die habe ich mit der Installation einer gängigen Distribution nicht zur Verfügung. Es kann schon sein, das ThinClient-Lösungen gefragt sind, aber das ist kein Argument, die Transparenzen nicht anzubieten. Das mit den runden Fenstern wird übrigens richtig ekelhaft, wenn man runde OpenGL-Contexte verwendent und dann Render2Texture macht. Ich benutze X11 auch nicht direkt. Ich wollte das mal machen, aber hab es dann wg. der Komplexität gelassen. Ich nutze auch Qt, aber weist du, warum der QPainter kein Alphablending kann? Weil das unter X11 nicht zu realisieren ist. Ich wette mit dir, wenn Alphablending unter X11 verfügbar ist, wird das auch in Qt verwendet. Auf den anderen Zielplatformen steht das ja schon zur Verfügung.

  6. #51
    Administrator Avatar von anda_skoa
    Registriert seit
    17.11.2001
    Ort
    Graz, Österreich
    Beiträge
    5.477
    Original geschrieben von axeljaeger
    Ich hab die Möglichkeiten getestet, die mir Mandrake Linux bietet. Das ist wahrscheinlihc XFree86. Möglicherweise gibt es kommerzielle Systeme, die das anders handhaben, aber die habe ich mit der Installation einer gängigen Distribution nicht zur Verfügung.
    Nunja, dann schlage ich vor, du bist bishen vorsichtiger mit "wird es nie geben"- oder "geht unter X11 nicht"-Behauptungen


    Es kann schon sein, das ThinClient-Lösungen gefragt sind, aber das ist kein Argument, die Transparenzen nicht anzubieten.
    Nein, hab ich auch nie behauptet. Aber es ist ein Argument gegen das Fallenlassen der Netzwerktransparenz, was komischerweise immer wieder als Allheilmittel hingestellt wird, wo es doch eigentlich keine Einschränkung darstellt.

    Scheint auf einer komische Logik zu fußen: "Windows ist nicht netzwerktransparent und hat visuelle Gimicks, daher muss offensichtlich die Netzwerktransparenz in X11 Schuld sein, dass es diese Gimicks nicht gibt".


    Das mit den runden Fenstern wird übrigens richtig ekelhaft, wenn man runde OpenGL-Contexte verwendent und dann Render2Texture macht.
    Glaub ich dir gerne, da hat du mehr Erfahrung als ich.
    Ich benutze ja nicht mal Applikationen mit runden Fenstern, geschweige denn, dass ich sowas programmiert hätte.

    Ich nutze auch Qt, aber weist du, warum der QPainter kein Alphablending kann? Weil das unter X11 nicht zu realisieren ist. Ich wette mit dir, wenn Alphablending unter X11 verfügbar ist, wird das auch in Qt verwendet. Auf den anderen Zielplatformen steht das ja schon zur Verfügung.
    Ich denke die Wette hast du schon gewonnen, hab es gerade ausprobiert und QPainter hatte kein Problem mit dem Alphachannel

    Code:
    #include <qapplication.h>
    #include <qimage.h>
    #include <qlabel.h>
    #include <qpainter.h>
    #include <qpixmap.h>
    
    int main(int argc, char** args)
    {
        QApplication app(argc, args);
    
        QImage image(256, 256, 32);
        image.setAlphaBuffer(true);
        for (uint y = 0; y < 256; ++y)
        {
            for(uint x = 0; x < 256; ++x)
            {
                image.setPixel(x, y, qRgba(255, 0, 0, x));
            }
        }
    
        QPixmap pixmap(256, 256);
        QPainter painter;
        painter.begin(&pixmap);
        painter.fillRect(0, 0, 256, 256, Qt::blue);
        painter.drawImage(0, 0, image);
        painter.end();
    
        QLabel label(0);
        label.resize(256, 256);
        label.setPixmap(pixmap);
    
        app.setMainWidget(&label);
        label.show();
        return app.exec();
    }
    Ciao,
    _
    Qt/KDE Entwickler
    Debian Benutzer

  7. #52
    Registrierter Benutzer
    Registriert seit
    08.07.2002
    Beiträge
    719
    Das man ein QImage mit Alphabuffer malen kann, ist klar. Aber versuch mal, die Stiftfarbe des Painters auf halbdurchlässig zu setzen, oder einen Kreis mit einem transparenten Rotton zu füllen. Das geht nämlich nicht. Außerdem muss man dazusagen, dass QPainter::drawImage alles andere als schnell ist, weil intern das QImage erstmal in eine QPixmap umgewandelt wird.

  8. #53
    Administrator Avatar von anda_skoa
    Registriert seit
    17.11.2001
    Ort
    Graz, Österreich
    Beiträge
    5.477
    Original geschrieben von axeljaeger
    Das man ein QImage mit Alphabuffer malen kann, ist klar. Aber versuch mal, die Stiftfarbe des Painters auf halbdurchlässig zu setzen, oder einen Kreis mit einem transparenten Rotton zu füllen. Das geht nämlich nicht.
    Da hast du recht, gerade ausprobiert.
    Scheinbar ignorieren die Zeichenfunktionen den Alphawert der Farbe.

    Ist die Frage, warum sie das tun, da es ja offensichtlich geht wenn man ein QImage zeichnet.
    Als Pixmap Maske kann man auch nur zwischen volltransparent und undurchlässig wählen, da fragt man sich schon, wie man dann ein Image mit Aplhachannel zeichnen kann.


    Außerdem muss man dazusagen, dass QPainter::drawImage alles andere als schnell ist, weil intern das QImage erstmal in eine QPixmap umgewandelt wird.
    Ja, schon klar, war nur die einfachste Möglichkeit Bilddaten mit Alphachannel zu bekommen.
    Wie sich jetzt rausstellte, die einzige.

    Hmm, ich frag mich, wie die das in KHTML gelöst haben.

    Ciao,
    _
    Qt/KDE Entwickler
    Debian Benutzer

  9. #54
    Registrierter Benutzer
    Registriert seit
    16.09.2001
    Beiträge
    1.182

    X ist langsam...

    So, das ist jetzt eine Aufgabe gewesen, wo ich ein QT2.3-Programm grafikintensive Aufgaben machen lassen habe (In Eagle die Bauteilliste runtergescrollt), und das kommt dabei raus:

    X: ~60%
    Eagle: ~20%

    Was bedeutet, das Eagle für die ganzen QT-Wrapper-Funktionalitäten, eigenen Funktionen, encoding nach X-LIB 20% der verfügbaren Prozessorzeit benötigt, während sich der X-Server nur zum decodieren und anzeigen die restlichen 60% schnappt.

    Unter Windows2000 steigt bei diesem Test die Kernellast auf 5% (weil ja grafiksubsystem im kernel), eagle brauch 15% prozessorzeit....
    Geändert von Lin728 (19-08-2017 um 21:37 Uhr)

  10. #55
    Registrierter Benutzer
    Registriert seit
    08.07.2002
    Beiträge
    719
    Original geschrieben von anda_skoa
    Da hast du recht, gerade ausprobiert.
    Scheinbar ignorieren die Zeichenfunktionen den Alphawert der Farbe.

    Ist die Frage, warum sie das tun, da es ja offensichtlich geht wenn man ein QImage zeichnet.
    Als Pixmap Maske kann man auch nur zwischen volltransparent und undurchlässig wählen, da fragt man sich schon, wie man dann ein Image mit Aplhachannel zeichnen kann.

    Ja, schon klar, war nur die einfachste Möglichkeit Bilddaten mit Alphachannel zu bekommen.
    Wie sich jetzt rausstellte, die einzige.

    Hmm, ich frag mich, wie die das in KHTML gelöst haben.
    Das ist doch ein äußerst interessantes Phänomen. Wenn der QPainter bei seinen Zeichenroutinen den Alphachannel unterstützen würde, wäre es denke ich, kein so großes Ding mehr, auch die Kantenglättung für Shapes einzuführen. Wenn nicht mehr jeder seine Grafikfunktionen selber programmieren müsste, gäbe es eine Schwämme an Vektorzeichenprogrammen für Linux. Es war ja wohl eine große Innovation in Qt 3, das endlich QPixmaps mit Alphachannel untersützt werden, damit war es endlich möglich, Icons mit Dropshadow zu machen. Mich würde aber auch mal interessieren, was für eine Maske diese Pixmaps haben.

  11. #56
    Administrator Avatar von anda_skoa
    Registriert seit
    17.11.2001
    Ort
    Graz, Österreich
    Beiträge
    5.477
    Original geschrieben von axeljaeger
    Das ist doch ein äußerst interessantes Phänomen. Wenn der QPainter bei seinen Zeichenroutinen den Alphachannel unterstützen würde, wäre es denke ich, kein so großes Ding mehr, auch die Kantenglättung für Shapes einzuführen.
    Ich muss mir mal die Zeichenfunktionen genauer ansehen, aber wenn die QColor:ixel() benutzen, ist das die Limitierung.
    QRgba(255, 0, 0, 0) und QRgba(255, 0, 0, 255) haben dort nämlich den selben Wert.
    Wenn die Zeichnfunktionen mit den qRed, qGreen, qBlue Funktionen arbeiten, wäre es vielleicht machbar (denn dann könnte man qAlpha auch verwenden, wenn es das PaintDevice unterstützt)

    Wäre interessant, ob diese Limitierung nur in der X11 Version existiert, oder auch auf Windows oder OSX


    Wenn nicht mehr jeder seine Grafikfunktionen selber programmieren müsste, gäbe es eine Schwämme an Vektorzeichenprogrammen für Linux.
    AFAIK benutzen die meisten da ohnehin libart_lgpl.
    Ist zum Beispiel eines der möglichen Renderebackends von KSVG

    Für Vektorgrafik ist QPainter auch sonst ziemlich eingeschränt, der kann zum Beispiel nur int Koordinaten, die Vektorleute hätten gerne double (siehe Diskussionen über KPainter auf koffice-core-devel)


    Mich würde aber auch mal interessieren, was für eine Maske diese Pixmaps haben.
    Hab mal ein bischen reingeschaut.
    Da wird QImage::createAlphaMask gemacht und das Resultat dann an ein QBitmap zugewiesen und das wird am Resultat Pixmap als Mask gesetzt.

    Werd mir heute mal ansehen, wie das Ergebnis von createAlphaMask aussieht.

    Ciao,
    _
    Qt/KDE Entwickler
    Debian Benutzer

  12. #57
    Registrierter Benutzer
    Registriert seit
    08.07.2002
    Beiträge
    719
    Original geschrieben von anda_skoa
    Ich muss mir mal die Zeichenfunktionen genauer ansehen, aber wenn die QColor:ixel() benutzen, ist das die Limitierung.
    QRgba(255, 0, 0, 0) und QRgba(255, 0, 0, 255) haben dort nämlich den selben Wert.
    Wenn die Zeichnfunktionen mit den qRed, qGreen, qBlue Funktionen arbeiten, wäre es vielleicht machbar (denn dann könnte man qAlpha auch verwenden, wenn es das PaintDevice unterstützt)

    Wäre interessant, ob diese Limitierung nur in der X11 Version existiert, oder auch auf Windows oder OSX

    Schau dir das mal genau an, wäre schön, wenn man das eingebaut bekäme.

    Original geschrieben von anda_skoa

    AFAIK benutzen die meisten da ohnehin libart_lgpl.
    Ist zum Beispiel eines der möglichen Renderebackends von KSVG
    Stimmt, ich auch. Nur leider kann man unter GTK das, was einem libart rendert, schneller auf den Schirm bekommen, weil man bei Qt ja nur in ein QImage und nicht in eine QPixmap zeichnen kann. Ich hab das umgangen, indem ich OpenGL verwendet habe. Die App rennt und ich kann bei z.B. Selektionen auch mal die Selektion ohne Performanceverlust pulsieren lasen.

    Original geschrieben von anda_skoa

    Für Vektorgrafik ist QPainter auch sonst ziemlich eingeschränt, der kann zum Beispiel nur int Koordinaten, die Vektorleute hätten gerne double (siehe Diskussionen über KPainter auf koffice-core-devel)
    Flash benutzt intern auch keine Doubles, sondern int. Nur nehmen die nicht Pixel als Maßeinheit, sondern Twips ( den zwanzigsten Teil eines Punktes )

    Original geschrieben von anda_skoa

    Hab mal ein bischen reingeschaut.
    Da wird QImage::createAlphaMask gemacht und das Resultat dann an ein QBitmap zugewiesen und das wird am Resultat Pixmap als Mask gesetzt.

    Werd mir heute mal ansehen, wie das Ergebnis von createAlphaMask aussieht.
    Interessant, weil QBitmap ja eher für eine AlphaMaske denn einen AlphaKanal geeignet zu sein scheint.

  13. #58
    Administrator Avatar von anda_skoa
    Registriert seit
    17.11.2001
    Ort
    Graz, Österreich
    Beiträge
    5.477
    Original geschrieben von axeljaeger
    Schau dir das mal genau an, wäre schön, wenn man das eingebaut bekäme.
    Ich muss mal in der Firma unter Windows ein Beispiel ausprobieren, wo mit einer Pen Color mit Alphawert gezeichnet wird.


    Stimmt, ich auch. Nur leider kann man unter GTK das, was einem libart rendert, schneller auf den Schirm bekommen, weil man bei Qt ja nur in ein QImage und nicht in eine QPixmap zeichnen kann.
    In welcher Form liefert libart das Ergebnis?


    Ich hab das umgangen, indem ich OpenGL verwendet habe. Die App rennt und ich kann bei z.B. Selektionen auch mal die Selektion ohne Performanceverlust pulsieren lasen.
    Für was animierte ist das wahrscheinlich eh fast am zielführendsten, sicher am perfomantesten.


    Flash benutzt intern auch keine Doubles, sondern int. Nur nehmen die nicht Pixel als Maßeinheit, sondern Twips ( den zwanzigsten Teil eines Punktes )
    Ich bin bei meiner Vektorgraphiklib auch mit ints ausgekommen, aber das war halt einer der Kritikpunkte in der Diskussion aof koffice-devel.
    AFAIK überlegen einige Karbon14 Entwickler, eine eigene Painter/PaintDevice Infrastruktur zu machen, vielleicht ist da auch schon Code in kdenonbeta.


    Interessant, weil QBitmap ja eher für eine AlphaMaske denn einen AlphaKanal geeignet zu sein scheint.
    Scheint auch bei meinem Beispiel mit dem Alphagradienten überall 1 zu sein, also "Vordergrund".
    Soweit ich jetzt glaube zu wissen wird das Image bei Aplhakanalbenutzung über XRender gezeichnet.

    Ciao,
    _
    Qt/KDE Entwickler
    Debian Benutzer

  14. #59
    Registrierter Benutzer
    Registriert seit
    08.07.2002
    Beiträge
    719
    Original geschrieben von anda_skoa
    Ich muss mal in der Firma unter Windows ein Beispiel ausprobieren, wo mit einer Pen Color mit Alphawert gezeichnet wird.
    Ach, unter Windows geht das?
    Original geschrieben von anda_skoa

    In welcher Form liefert libart das Ergebnis?
    Man gibt einen char-buffer als Ziel fürs rendering an. QImage.bits() eignet sich, man kann aber auch selber was mallocen.
    Original geschrieben von anda_skoa

    Für was animierte ist das wahrscheinlich eh fast am zielführendsten, sicher am perfomantesten.
    In der Tat.

  15. #60
    Registrierter Benutzer
    Registriert seit
    16.09.2001
    Beiträge
    1.182
    quote:Original geschrieben von anda_skoa

    Für was animierte ist das wahrscheinlich eh fast am zielführendsten, sicher am perfomantesten.

    In der Tat.
    Da sind wir wieder da. X ist zu langsam...

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •