В конкретно этом случае (т.к. передаёте JPEG), лучше просто использовать Texture2D.FromStream().
Он вообще-то понимает и .jpg и .png.
А вообще лучший (из простых) вариант разбить всю картинку по сетке и передавать только изменившиеся куски.
А с некоторой задержкой (раз N секунд) передавать все.
Ну или (при двустороннем общении), по запросу клиента.
Ага, а ещё стоит обратить внимание на то, что у этой клавы по умолчанию включен режим Office.
У сына такая стоит — каждый раз садясь за неё хочется поубивать этих гениальных инженеров. Причём меееедленно.
Вообще-то это должно зависить от (пардон) текущего выделения.
Если есть выделенный блок — делаем Copy. Нет — делаем Paste.
Paste с заменой не рассматриваем.
Для случая с текстом весьма просто реализуемо программно, с привязкой к одному клавише-сочетанию (а то и просто к одной клавише).
Назваем каким-нибудь «супер-пупер контекстно-зависимым механизмом копирования-вставки» и радуемся жизни.
И git и mercurial куда удобнее svn.
На больших проектах — отпадает проблема «либо коммиты рабочие либо нормальная история изменений».
На маленьких — получаешь локальный репозиторий безо всяких заморочек.
К командной строке привыкаешь за день, если нужно что-то хитрое — 5 минут гугления решают большинство вопросов. Реально за месяц привыкаешь так, что назад уже не потянет. Для тех, кто не может жить без GUI тоже есть из чего выбрать.
Если честно, то только с DVCS привык в каждом проекте использовать контроль версий.
Даже в малюсеньких типа «можно сделать ручками за полчаса, напишу программулю за 15 минут и 15 минут могу честно-заработанно валять дурака». :)
Единственная проблема от перехода — после него будете смотреть на svn/cvs репозитории как на нечто хоть и близкое-знакомое, но какое-то старое и несчастное.
А я бы предложил собирать в bin не одну (основную) сюжетную ветку, а несколько.
В идеале — в конец каждой части добавить ссылки — варианты например «А Вася-то гад» и «Вася — герой».
Это, естественно возможно только для тех форматов, которые поддерживают ссылки (либо сноски).
Это не идиотизм, а всего лишь капля в океане того уважения, что эти Люди заслужили. P.S.: Сливайте сколько угодно, на моём отношении к ним это никак не скажется.
Дело не Ваших ассоциациях, а в восприятии этого слова теми немногими оставшихся, кто пережил ту войну. Для них это не что иное, как очередной плевок.
И судя по написанному, в том числе и от Вас.
Если распределение более-менее ровное (например, ключ это MD5 хеш чего-либо), в качестве хеша для индекса/поиска есть смысл использовать, скажем, первые 3 байта ключа.
Создаём List|Array[0xFFFFFF], содержащий List со ссылками|смещениями элементов.
Вариант с вложенностью — основной List|Array[0xFFFFFF] содержит под-уровни (в зависимости от распределения ключа выбираем либо List либо Array), а они уже либо точное значение (для полного индекса ключа, если памяти не жалко), либо те же List со ссылками|смещениями элементов.
В сжатие данных эта техника называется DirectBytes.
И при всей своей простоте позволяет достичь весьма высокой скорости.
Единственный минус — требования по памяти в случае полного индекса, ну оно и понятно.
Кстати, очень советую посмотреть в сторону memory mapped files и уйти от хранения в памяти.
Тогда можно будет сделать действительно масштабируемую версию, а кроме того (если при изменении сохранять индекс в файл) ещё и с очень быстрой инициализацией.
Если со строками не повезёт и ключ окажется GUID'ным — советую инвертировать его побайтно (задом наперёд переписать то есть). Распределение будет со смещением в начало, а соответсвенно вырастет скорость поиска.
Если нужно добавление записей дибо изменение ключа — сортировка не вариант.
Я бы использовал для индекса что-нибудь максимально простое, ориентируясь на производительность.
Маппинг «N байт ключа»- «список указателей». Либо вариант со вложенным маппингом.
В зависимости от распределения ключа можно выбрать для маппинга либо List/Array либо Dictionary.
А вот древо я бы поостерёгся использовать, по крайней мере в универсальной реализации.
Кроме того, я бы не грузил все данные в память, а использовал бы memory mapped files.
Кстати, судя по тому, что ключ — строка, в реальном мире его скорее всего можно было бы ужать в более компактное битовое представление.
Можно обойтись и без сортировки.
Да и затраты на загрузку 1M записей в Вашем варианте всяко будут велики. В «массивном» варианте скорость загрузки выше.
А реализация индекса может быть какой угодно.
@echo %*И запуск с параметрами
Easter EggТак даже функциональность имеется по умолчанию.
EasterEgg.bat:
@echo %~n0А для тех, кто
в танкек празднику отношения не имеет, можно в конце pause добавить.В конкретно этом случае (т.к. передаёте JPEG), лучше просто использовать Texture2D.FromStream().
Он вообще-то понимает и .jpg и .png.
А вообще лучший (из простых) вариант разбить всю картинку по сетке и передавать только изменившиеся куски.
А с некоторой задержкой (раз N секунд) передавать все.
Ну или (при двустороннем общении), по запросу клиента.
Receive_GetData и ConvertToTexture2D это нечто.
1. Преобразуем byte[] в Bitmap.
2. Сохраняем Bitmap в PNG.
3. Загружаем Texture2D из PNG.
… и всё это вместо одного вызова Texture2D.SetData().
IE9 выйдет немного позже pwn2own, причём с уже закрытыми уязвимостями IE8.
У сына такая стоит — каждый раз садясь за неё хочется поубивать этих гениальных инженеров. Причём меееедленно.
Если есть выделенный блок — делаем Copy. Нет — делаем Paste.
Paste с заменой не рассматриваем.
Для случая с текстом весьма просто реализуемо программно, с привязкой к одному клавише-сочетанию (а то и просто к одной клавише).
Назваем каким-нибудь «супер-пупер контекстно-зависимым механизмом копирования-вставки» и радуемся жизни.
На больших проектах — отпадает проблема «либо коммиты рабочие либо нормальная история изменений».
На маленьких — получаешь локальный репозиторий безо всяких заморочек.
К командной строке привыкаешь за день, если нужно что-то хитрое — 5 минут гугления решают большинство вопросов. Реально за месяц привыкаешь так, что назад уже не потянет. Для тех, кто не может жить без GUI тоже есть из чего выбрать.
Если честно, то только с DVCS привык в каждом проекте использовать контроль версий.
Даже в малюсеньких типа «можно сделать ручками за полчаса, напишу программулю за 15 минут и 15 минут могу честно-заработанно валять дурака». :)
Единственная проблема от перехода — после него будете смотреть на svn/cvs репозитории как на нечто хоть и близкое-знакомое, но какое-то старое и несчастное.
В принципе, можно устраивать «голосование» через github'овские issues.
В идеале — в конец каждой части добавить ссылки — варианты например «А Вася-то гад» и «Вася — герой».
Это, естественно возможно только для тех форматов, которые поддерживают ссылки (либо сноски).
Таким образом получится «интерактивная книга» :)
Лично мне помогли:
code.google.com/p/apps-for-android/
en.wikipedia.org/wiki/List_of_open_source_Android_applications
Думаю, есть смысл добавить в статью, как источник кода для как-это-делается.
P.S.: Сливайте сколько угодно, на моём отношении к ним это никак не скажется.
И судя по написанному, в том числе и от Вас.
Создаём List|Array[0xFFFFFF], содержащий List со ссылками|смещениями элементов.
Вариант с вложенностью — основной List|Array[0xFFFFFF] содержит под-уровни (в зависимости от распределения ключа выбираем либо List либо Array), а они уже либо точное значение (для полного индекса ключа, если памяти не жалко), либо те же List со ссылками|смещениями элементов.
В сжатие данных эта техника называется DirectBytes.
И при всей своей простоте позволяет достичь весьма высокой скорости.
Единственный минус — требования по памяти в случае полного индекса, ну оно и понятно.
Кстати, очень советую посмотреть в сторону memory mapped files и уйти от хранения в памяти.
Тогда можно будет сделать действительно масштабируемую версию, а кроме того (если при изменении сохранять индекс в файл) ещё и с очень быстрой инициализацией.
Если со строками не повезёт и ключ окажется GUID'ным — советую инвертировать его побайтно (задом наперёд переписать то есть). Распределение будет со смещением в начало, а соответсвенно вырастет скорость поиска.
Не за что :)
Я бы использовал для индекса что-нибудь максимально простое, ориентируясь на производительность.
Маппинг «N байт ключа»- «список указателей». Либо вариант со вложенным маппингом.
В зависимости от распределения ключа можно выбрать для маппинга либо List/Array либо Dictionary.
А вот древо я бы поостерёгся использовать, по крайней мере в универсальной реализации.
Кроме того, я бы не грузил все данные в память, а использовал бы memory mapped files.
Кстати, судя по тому, что ключ — строка, в реальном мире его скорее всего можно было бы ужать в более компактное битовое представление.
Да и затраты на загрузку 1M записей в Вашем варианте всяко будут велики. В «массивном» варианте скорость загрузки выше.
А реализация индекса может быть какой угодно.
Лишь бы памяти хватило.
Да и про разбиение уже не раз сказали.