Другое > Программирование (любое)
Каким яп можно быстро манипулировать пикселями? (выбор яп)
Samovar:
--- Цитировать ---Привет. Вот приспичило мне обрабатывать некими алгоритмами массив точек(пикселей) области экрана. Чтобы была анимация неких генерируемых процессов в реальном(хотелось бы быстро чтобы наглядно) времени. Встал вопрос выбора подходящего инструмента - языка программирования. Подходящего для задачи и подходящего такому программисту, как я(в коде ниже возможна куча ошибок).
Для теста скорости отрисовки конкретным языком(библиотекой) решил просто рисовать массив точек черного или белого цвета. Как белый шум на экране аналогового тв, когда нет сигнала. И посмотреть сколько кадров в секунду вообще возможно рисовать. Ведь я еще даже не буду обрабатывать массив точек по нужному мне алгоритму, просто рандом(белый ИЛИ черный).
Попробовал Free Pascal(Lazarus). Если в лоб, то очень медленно. С разрешением поля 800х600 всего 3.5 к/с(кадров в секунду).
--- Конец цитаты ---
Именно из-за графики я и выбрал Freebasic. Да и с детства знаю этот ЯП.
Есть свои нюансы, естественно... но всё работает "из коробки" :)
Позже отпишусь по твоему вопросу более подробно... ты не запрещаешь прерывания, когда производишь отрисовку в видеобуфер: Screenlock, Scsreenunlock, потому у тебя и медленно... да куча там ещё вещей...
Striver:
По хорошему не должно быть НИКАКИХ попиксельных записей/чтений в видеопамять. Вся индивидуальная работа с отдельными пискселями должна вестись с буфером в обычной памяти, а после всех циклов нужно выгружать этот буфер в видеопамять одной командой. Именно так, насколько я понял, работает второй (а, может, и первый тоже, тонкостей библиотеки Processing не знаю) вариант программы на яве, поэтому он быстрее всех и получился.
Наверное, альтернативой этому могла бы быть возня с пикселями через шейдеры чисто внутри видеопамяти, но тогда и алгоритмы придётся на glsl писать.
LanuHum:
Не знаю, чем вы тут занимаетесь, но, мне кажется стоит посмотреть в сторону готовых графических библиотек. Зачем рисовать на экране, если можно рисовать в окне в полно экранном режиме в уже приспособленных для этих целей программах
https://www.opennet.ru/docs/RUS/gtk_plus/x2486.html
или Simple C++ OpenGL program to draw points on a 2D canvas :
--- Код ---
#include<GL/glut.h>
void display() {
glClear(GL_COLOR_BUFFER_BIT);
glColor3f(1.0, 0.0, 0.0);
glBegin(GL_POINTS);
glVertex2f(10.0, 10.0);
glVertex2f(150.0, 80.0);
glVertex2f(100.0, 20.0);
glVertex2f(200.0, 100.0);
glEnd();
glFlush();
}
void myinit() {
glClearColor(1.0, 1.0, 1.0, 1.0);
glColor3f(1.0, 0.0, 0.0);
glPointSize(5.0);
glMatrixMode(GL_PROJECTION);
glLoadIdentity();
gluOrtho2D(0.0, 499.0, 0.0, 499.0);
}
void main(int argc, char** argv) {
glutInit(&argc, argv);
glutInitDisplayMode(GLUT_SINGLE | GLUT_RGB);
glutInitWindowSize(500, 500);
glutInitWindowPosition(0, 0);
glutCreateWindow("Points");
glutDisplayFunc(display);
myinit();
glutMainLoop();
}
--- Конец кода ---
Samovar:
--- Цитировать ---Не знаю, чем вы тут занимаетесь, но, мне кажется стоит посмотреть в сторону готовых графических библиотек.
--- Конец цитаты ---
Ответ на твой вопрос, Ланухумыч:
--- Цитировать --- Еще напишу, что хочется писать алгоритм обработки массива(вместо rand), а не длиннющие портянки кода инициализации и работы с OpenGl напрямую.
--- Конец цитаты ---
Samovar:
--- Цитировать ---По хорошему не должно быть НИКАКИХ попиксельных записей/чтений в видеопамять. Вся индивидуальная работа с отдельными пискселями должна вестись с буфером в обычной памяти, а после всех циклов нужно выгружать этот буфер в видеопамять одной командой.
--- Конец цитаты ---
Абсолютносогласен.
Навигация
Перейти к полной версии