crypt of decay - Post a comment [entries|archive|friends|userinfo]
ketmar

[ userinfo | ljr userinfo ]
[ archive | journal archive ]

Oct. 26th, 2020|09:49 pm

ketmar
ну вот я имею опыт с той же libpng, и считаю её уёбищем. я не знаю, какие задачи она должна решать — но задачи удобной работы с png она не решает вообще. как раз потому, что у неё в принципе такой цели не было, у неё была цель «реализовать стандарт». в итоге я или пинаю imlib2 (которая тоже не сахар, но намного удобней для простых целей), или вообще взял из гоззы minipng и глобально обработал напильником (потому что идиот; лучше бы с нуля написал).

с либжопег, по ходу, всё ещё хуже. но там вдобавок формат уёбищный, и dct, и мне лень как парзер пилить, так и dct, так что при необходимости возьму, наверное, её. или спизжу код из stb_image.

для fft мне хватало kissfft. ну, у меня не было задач, где скорость настолько критична. были бы — наверное, взял бы fftw.

это всё ещё к той тонкой границе между нежеланием запариваться неудобными библиотеками и маниакальным желанием всё написать с нуля самому. однако почти все эти библиотеки всё равно неудобны — именно за счёт их универсальности.

реально — супероптимизирование по скорости далеко не всегда важно. и библиотеки часто берут «на вырост», кстати. ту же sqlite: да камон, её часто тянут туда, где достаточно было бы наколенного балансированого дерева с простейшим mmap (если ни вообще тупо массива с линейным/двоичным поиском). а картинку часто можно imagemagic-ом конвертнуть в какую-нибудь pnm и читать результат из stdin. и ты пы.
Link Read Comments

Reply:
From:
(will be screened)
Identity URL: 
имя пользователя:    
Вы должны предварительно войти в LiveJournal.com
 
E-mail для ответов: 
Вы сможете оставлять комментарии, даже если не введете e-mail.
Но вы не сможете получать уведомления об ответах на ваши комментарии!
Внимание: на указанный адрес будет выслано подтверждение.
Username:
Password:
Subject:
No HTML allowed in subject
Message: