Back to archive
#ai#agents#coding-agents

Paint.NET testuje bibliotekę Direct2D napisaną głównie przez Claude’a

Paint.NET 5.2 Alpha można eksperymentalnie uruchomić w Wine dzięki własnej bibliotece Direct2D. Według autora programu Claude w trzy tygodnie napisał większość z około 180 tys. linii tej biblioteki. Rozwiązanie omija braki Wine, ale nie przeszło pełnego przeglądu; autor opisuje je jako wolne i niestabilne.

Co się wydarzyło

Paint.NET 5.2 Alpha w kompilacji 9739 można eksperymentalnie uruchomić w Wine na Linuksie. Po użyciu parametru /wine program omija niepełną obsługę Direct2D w Wine i ładuje własny odpowiednik tej biblioteki. Został napisany od zera w zarządzanym kodzie i znajduje się w pliku PaintDotNet.Windows.Direct2D1.Managed.dll.

Według Ricka Brewstera, autora Paint.NET, Claude napisał większość z około 180 tys. linii nowej biblioteki w ciągu trzech tygodni. Brewster przejrzał kod łączący ją z aplikacją, lecz nie zdołał przeczytać całej implementacji. Podczas pracy znalazł między innymi brak odpowiednika AddRef() dla obiektów COM oraz złe decyzje architektoniczne. Ostrzega, że obecna wersja jest wolna, niestabilna i nie nadaje się jeszcze do zwykłej pracy.

Co potwierdzają źródła

Oficjalne wydanie w serwisie GitHub potwierdza numer kompilacji, wersję przenośną i osobną instrukcję dla Wine. Do uruchomienia potrzeba co najmniej Wine 11.14 oraz DXVK. Trzeba też skonfigurować Wine tak, by używał dołączonej wersji d3dcompiler_47. Program uruchamia się następnie z parametrem /wine. Już wcześniejsza kompilacja 9719 dodała przełączniki wyłączające elementy animacji i kompozycji, które nie działały poprawnie w Wine.

Społecznościowy projekt Paint.NETOnWine opisywał te przeszkody jeszcze przed premierą. Nowe wersje programu mocno zależą od niepełnych implementacji Direct2D i UIAnimation w Wine; według ówczesnego opisu seria 5.2 ulegała awarii przy uruchamianiu. Repozytorium zawiera również wcześniejsze poprawki do Wine i skrypty przygotowane przez kilku współtwórców. Ludzie zdążyli więc opisać i częściowo rozpracować problem, zanim do pracy użyto Claude’a.

Pierwszym niezależnym śladem działania nowej wersji jest zgłoszenie w WineHQ. Jego autor uruchomił kompilację 9739 na Wine 11.16, podał sumę kontrolną pobranego archiwum i opisał zbyt szerokie okno narzędzi. Wiemy więc, że aplikacja się otworzyła. Zgłoszenie nic nie mówi o poprawności renderowania. Chiński serwis Solidot opisał premierę i sposób instalacji, ale nie przetestował samej biblioteki Direct2D.

Nie da się niezależnie sprawdzić liczby linii, udziału Claude’a ani deklaracji, że nowy kod powstał bez zaglądania do źródeł oryginalnej biblioteki. Źródła Paint.NET są zamknięte, a repozytorium wydania zawiera tylko plik README i gotowe paczki. Te trzy twierdzenia opierają się wyłącznie na relacji Brewstera. Zewnętrznego audytu kodu nie opublikowano.

Co mówi dyskusja

Starsze rozmowy użytkowników Wine i Paint.NET od lat wracały do tego samego problemu: współczesne wydania programu nie działały na Linuksie z powodu braków w Direct2D i UIAnimation. Nowa kompilacja omija znaną przeszkodę, ale opublikowano dotąd zbyt mało testów, by ocenić zgodność efektów, szybkość działania i liczbę awarii na różnych dystrybucjach.

Najtrudniejsze pytanie brzmi: jak sprawdzić 180 tys. linii kodu, których człowiek nie jest w stanie przeczytać? Brewster porównuje obrazy generowane przez nową bibliotekę z wynikami wersji referencyjnej i testuje zachowanie całej aplikacji. Tak można wykryć źle narysowany efekt, ale łatwiej przeoczyć wycieki zasobów, błędy czasu życia obiektów lub konstrukcję kodu, którą trudno później utrzymać. Brak AddRef() jest przykładem błędu, którego sam obraz może nie ujawnić.

Wnioski

Brewster wybrał architekturę, przygotował środowisko, połączył bibliotekę z aplikacją i poprawiał błędy. Społeczność wcześniej rozpoznała braki po stronie Wine. Według Brewstera praca z Claude’em pozwoliła w trzy tygodnie stworzyć komponent o rozmiarze odpowiadającym mniej więcej jednej czwartej pozostałego kodu Paint.NET. Nikt niezależny nie potwierdził tego czasu ani udziału modelu.

Przy takiej objętości ręczne przeczytanie każdej zmiany przestaje być możliwe. Brewster musi polegać na porównaniach z wersją referencyjną, testach zachowania programu i ostrożnym udostępnianiu funkcji. Na razie nową bibliotekę można badać, ale nie ma podstaw, by traktować ją jak gotowy składnik stabilnego wydania.

Czego jeszcze nie wiemy

Nie opublikowano wyników zgodności z Direct2D, pomiarów wydajności ani statystyk awarii. Nie wiadomo, jaką część kodu obejmują testy, kto będzie go utrzymywał i czy rozwiązanie trafi do stabilnej wersji programu. Zamknięte źródła utrudniają też ocenę ryzyka licencyjnego. Jedno zgłoszenie z WineHQ nie wystarcza, by potwierdzić działanie na większej liczbie konfiguracji.

Źródła

Źródła pierwotne

Niezależne analizy i relacje

Dyskusje publiczne

Wykorzystuję treści generowane przez AI jako część mojego codziennego procesu nauki.