Лопатится будет одно и то же изображение много раз или разные?

да это отрисовщик. лопатиться будет новый кадр.

Тогда просто пройтись по всем и все.

я сначала сделал цикл в цикле и всё. но как-то медленно это

Вообще надо знать конкретно, что делаться будет.

По идее просто перебор всех пикселей должен делаться быстро, если память не выделяется в цикле.

для начала, вызываться callback с передачей туда x, y, котрый будет отдавать цвет, который мы поставим в пиксель

хотя, даже не для начала, а вообще.

Ну вообще должно быстро быть, если не выделяется память при установке пикселя.

Пиксели просто случайные устанавливаются? И никакого вывода изображения не происходит в самом процессе?

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

В общем все должно работать быстро. А код посмотреть можно?

В общем все должно работать быстро. А код посмотреть можно?

https://github.com/kirillDanshin/go-wde/blob/master/wdetest/wdetest.go#L153

Гиф обязательно должнн быть?

Это осталось в наследство, да и не влияет, насколько я заметил

Гиф это изображение с палитрой. Соответственно, каждая установка пикселя будет искать похожий в палитре, хотя при текущих мощностях и не должно сильно сказываться. Я бы преобразовал к rgba, а потом придется по всем пикселям не через функции, а напрямую беря данные из Pix и туда же их записывая.

Надо бы придумать, как это сделать быстрым не меняя суть примера

распаралелить просчет, например

Я сейчас планшета и попробовать не выйдет, может и не правильно думаю. Создать еще одно изображение rgba, нарисовать на нем с помощью draw прочитанное и работать с ним.

Распаралеливать смысла нет. Эту дребидень даже на пеньке первом моментально должно сделать.

а если вместо многих ифов юзать кейс, то мб чуть чуть ускорит

это микрооптимизации

я почему вообще говорю об этом коде

на иксах проскакивает черный экран при ресайзе

и после долгого дебага мне тогда причину найти не удалось

кроме как скорость кода в цикле

Что насчет обработки на cuda?

А какое время занимает прорисовка изображения?

Какой там куда?! Там каьькулятор моментально сделает. )

На самом деле - вопрос в кеше проца и предсказании

Вообще проблема может быть просто в выводе.

Что насчет обработки на cuda?

nvidia у меня на убунте не хочет работать. да и потом, куда там cuda?

На самом деле - вопрос в кеше проца и предсказании

как это анализировать?

А какое время занимает прорисовка изображения?

сейчас замерю

Читать доку

Экспериментировать

Ну вот даже по количеству строк параллелизацию сделать. Правда, это будет медленней, скорей всего, чем перебор в лоб

Поговорить с Тутубалиным

Да не надо там параллельно ничего делать там же не хрен знает какое изображение.

Да не надо там параллельно ничего делать там же не хрен знает какое изображение.

этот тут не хрен знает. а вообще — хрен знает какое.

Поговорить с Тутубалиным

это ты о каком из говоришь?

А какое изображение? Какая размерность?

ну, в этом случае 300*300 в начале, а потом ресайз до скольки угодно

это ты о каком из говоришь?

Алексей, автор русского апача

Алексей, автор русского апача

окей, а в предсказании чего?

Ветвления

Подгрузки инфы в кеш из памяти

а если вместо многих ифов юзать кейс, то мб чуть чуть ускорит

можно разбить на зоны отрисовки и избавиться от большинства if-блоков (например как if x < width/2 && y <= height/2 {pxColor = green} ) но они почти не повысят производительность. основная потеря, я думаю, будет в получении и установке пикселя

кстати, думал о разбивке на зоны отрисовки. не придумал имплементацию.

предыдущий IF заменяется на for x := 0; x < w/2; x++ { for y:=0 y < h/2; x++ { s.Set(x, y, GREEN) }} если я правильно понимаю.

вообще для таких вещей в проекте (на C++, один из модулей системы наблюдения и ведения объекта) приходилось забивать на красоты и работать с картинкой как с одномерным блоком памяти. тогда на CPU можно было добиться нормальной скорости обработки (порядка 0.02..0.07 с на 1024x768 кадр в зависимости от. Правда там несколько сложнее, нежели просто получение / перекраска пикселя)

для нормальной скорости придётся зарыться в дебри CUDA / OpenCL

ребят, помогите понять в чем проблема создал чаны usersChan := make(chan vk.GroupsGetMembersVK) errorChan := make(chan vk.ParamsVKAPI) передаю в функцию go CounterPrints(usersChan, errorChan)

а вот функция func CounterPrints(usersChank <-chan interface{}, errorsChank <-chan interface{}) { chankUsersCount :=0 errorsCount := 0 tick := time.Tick(100 * time.Millisecond) for { select { case <-usersChank: chankUsersCount +=1 case <-errorsChank: errorsCount +=1 case <-tick: fmt.Printf("chankUsersCount:%w \n errorsCount:%w\n\n",chankUsersCount,errorsCount) } } }

просто счетчик

./hello.go:85: cannot use usersChan (type chan myvkapi.GroupsGetMembersVK) as type <-chan *interface {} in argument to CounterPrints ./hello.go:85: cannot use errorChan (type chan myvkapi.ParamsVKAPI) as type <-chan *interface {} in argument to CounterPrints почему ошибка?

потому, что типы разные

я пробовал сначала с однаковыми

стоп

заработало

непонятно, но да ладно

так interface{} это же любой тип, разве нет?

пустой интерфейс — это пустой интерфейс. но под него любые типы подходят, да

это и имел введу, интересно получается..

ERROR: S client not available

но спасибо

не за что

usersChan <- *r у меня зависает здесь код, почему? чан пустой func VkGetMembersGraber(params vk.ParamsVKAPI,usersChan chan vk.GroupsGetMembersVK,errorChan chan vk.ParamsVKAPI ) { r, err := vk.GroupGetMembersVKAPI(params ) if err != nil { fmt.Print("send to chan2") errorChan<- params } fmt.Print("send to chan1") usersChan <- *r }

может никто не читает оттуда?

ну так можно ж отправить, а потом принять разве не так?

сделал тест, и он нахрен завис

http://pastebin.com/G49UdRFd код теста

главный плюс го в многопоточности?

олег, если канал без буфера, то никуда отправить нельзя, пока с той стороны никто не читает

поэтому твой код и ждёт

олег, если канал без буфера, то никуда отправить нельзя, пока с той стороны никто не читает

понял

спасибо

https://tour.golang.org/concurrency/2

нужно пройти тур

прошол, но по ходу, не очень внимательно переводил..

если нужно, чтобы не больше 20 запросов одновременных на сервер было, как лутше сделать? я сделал костыль из for *inwork>19 { time.Sleep(25* time.Millisecond) }

в цикле где генерятся рутины

я бы запустил бы 20 горутинок, и передал бы им канал

и в канал бы этот писал урлы

елегантно

?

ну - стандартно для go

go-way

привыкнуть нужно)

и в канал бы этот писал урлы

а как определить что все урлы загрузились? чтоб отключить прогу юзать sync.WaitGroup ?

да

да

но горутины будуть ждать с канала данные в бесконечном цикле

слоожно

конечно, будут ждать

а потом снаружи канал закроют, и они выйдут

да, понял, круто! спасибо