Propozycja dodania interfejsu Cairo C++ do standardu ISO C++

10
1886

Herb Sutter – przewodniczący Komitetu Standaryzacyjnego C++ zaproponował, aby dodać interfejs Cairo C++ do przyszłych rewizji standardu ISO C++, w celu zapewnienia rysowania 2D. Samo Cairo jest napisane w języku C, ale posiada bardzo czysty i czytelny kod. Plany zakładają przekształcenie różnych konstrukcji języka C, na te w języku C++, np. funkcji _create w konstruktory. Dostępne są już dwa odpowiednie dokumenty: Lightweight Drawing Library – N3791 oraz N3825.

ŹRÓDŁOlists.cairographics.org
Poprzedni artykułCoreboot ze wstępną obsługą Allwinner A10 i Cubieboard
Następny artykułVirtualBox 3.2.12, 4.0.22, 4.1.30, 4.2.22
Michał Olber
Interesuję się głównie sprzętem i działaniem jego pod systemami GNU/Linux. Testuję różne dystrybucje i robię recenzje. Interesuję się działaniem sprzętu pod Linuksem, dzięki czemu wiem, jaki zestaw komputerowy wybierać :)

10 KOMENTARZE

  1. Pomysł nie głupi, ale skończy się na 4 różnych implementacjach z różnymi API pogłębiając różnice pomiędzy platformami, a MS stwierdzi że „mają lepszy pomysł” i nici z tego będą.

    • O ile to przejdzie to inni zwyczajnie tego nie zaimplementują, bo po co. Na swojej platformie i tak mają lepsze.

    • @sprae: Też myślę, że większość implementacji byłaby „C++1x bez cario” lub zabiłoby to standard C++ i nikt by nie aktualizował.

      Pominąć nie da się ofc sensowności wrzucania API do grafiki wektorowej do języka programowania… bez chociażby wbudowanej jakiejkolwiek możliwości prezentowania wyników (do tego trzeba użyć bibliotek, które… mają wbudowaną obsługę grafiki wektorowej). Kolejną sprawą jest bezsens dorzucania implementacji do kompilatora (co oznacza CPU only), czyli marnując możliwość wykorzystania sterowników ze sprzętową akceleracją (OpenVG). Za to czytając pobieżnie to co pisze Sutter, można dojść do wniosku chcemy Qt, ale wymaga sporej pracy od nas, chcemy coś niskopoziomowego, ale OpenGL/OpenVG są zbyt niskopoziomowe i są pisane typowo w C, to wybieramy Cario, które jest dosyć proste (nawet jeśli ma denerwujące api to nie wymaga tyle opisywania w specyfikacji co Qt i inne dobre api wektorowe), a API ma pisane w obiektowym stylu i CarioMM może być… o ile nie wygra 2ga opcja jaką rozważają czyli SVG+Canvas (coś w stylu HTML5 ;p).

    • Canvas to prawie to samo co Cairo. Cairo ma trochę więcej możliwości. Wszystko się opera na stosie PDF zaimplementowanym przez Apple. Mimo wszystko to jest trudne do akceleracji w GPU bez poczucia marnotrawstwa mocy obliczeniowej. A OpenVG nie jest zbyt popularne nawet na platformach, które sprzętowo je obsługują (Android).

      NVidia już wprowadziła rozszerzenie z obsługą ścieżek SVG? Kiedyś się chwalili, że jest wydajniejsze od implementacji Qt.

    • OpenVG jest popularne. Na androidzie nie jest, bo Google nie pozwala na dostęp do tego API, ani z SDK, ani z NDK (sprawa wygląda podobnie do OpenCL na Androidzie, które Google banuje, bo forsuje swoje RenderScript).

      Co do rozszerzenia to zapewne mówisz o sprzętowej akceleracji w OpenGL za pomocą GL_NV_path_rendering, który obsługuje pisanie fontami, SVG, PostScript.
      http://www.opengl.org/registry/specs/NV/path_rendering.txt

    • Od osadzonych po desktopowe – bardzo popularny jest na Symbian, WebOS i innych małych, po iOS i czasami Android przez implementacje w GLES (MonkVG), po desktopy (tu sporo programów wykorzystuje Qt z ich wsparciem dla OpenVG (QtOpenVG) plus implementacje zamknięte albo ShivaVG (oparta nie o OpenGL ES, a o OpenGL)).

ZOSTAW ODPOWIEDŹ

Proszę wpisać swój komentarz!
Proszę podać swoje imię tutaj