Вот то, что я считаю, происходит.По сути, модуль multiprocessing
работает, отправляя копии всего, что нужно target
новому интерпретатору;вот так он обходит GIL .Но это означает, что побочные эффекты (изменения в глобальных переменных, изменения в объектах, переданных, но не возвращенных), не распространяются должным образом.Вот простой пример:
>>> import multiprocessing
>>> d = {'a':5, 'b':6}
>>> def alter_d():
... d['a'] = 7
... print d
...
>>> p = multiprocessing(target=alter_d)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: 'module' object is not callable
>>> p = multiprocessing.Process(target=alter_d)
>>> p.start()
>>> {'a': 7, 'b': 6}
>>> d
{'a': 5, 'b': 6}
Итак, как вы можете видеть, версия d
, переданная новому процессу, была изменена.Но локальная версия d
остается прежней.
Теперь я ничего не знаю о внутренностях Pygame.Но я предполагаю, что когда вы создаете новый процесс с использованием logo = threading.Process(target=showlogo, args=())
, он создает копию screen
.Затем, либо когда создается эта копия, либо когда вызывается screen.blit(data.pictures.fc, (0,0))
внутри нового процесса, генерируется новый экран.
К счастью, то, как вы сейчас используете многопроцессорность, совершенно бессмысленно.join
просто останавливает основной процесс и ожидает завершения подпроцесса - параллелизма нет вообще.Кроме того, я бы поспорил, что pygame предоставляет все функции потоков, которые вам действительно нужны - я сомневаюсь, что вам вообще нужна многопроцессорная обработка.Я бы предложил, чтобы вы бросили это.