Комментарии 20
А почему нельзя было выбрать glsl для трансформаций и webGL/openGL для поворотов, обрезок, транфсформаций масштабов? Это столь же кроссплатформенно, но еще и считаться будет на GPU.
Для поворота итак используются функции canvas (в процессе анимации). Для поворотов на углы, кратные pi/2, в .NET используются стандартные методы, а в JavaScript манипуляция с пикселями. Кроме того, webGL, насколько я понимаю, сейчас плохо поддерживается браузерами.
Что касается использования GPU на сервере — да, мы об этом думали. Это возможно в будущем, если производительность не будет устраивать. Так то я переписывал на новую архитектуру старый код, работающий с System.Drawing. Если бы я занялся разработкой под GPU, то это заняло бы еще больше времени.
Кстати говоря, GPU мы планируем использовать на мобильных платформах, поскольку производительность там и вправду недостаточная.
Что касается использования GPU на сервере — да, мы об этом думали. Это возможно в будущем, если производительность не будет устраивать. Так то я переписывал на новую архитектуру старый код, работающий с System.Drawing. Если бы я занялся разработкой под GPU, то это заняло бы еще больше времени.
Кстати говоря, GPU мы планируем использовать на мобильных платформах, поскольку производительность там и вправду недостаточная.
Мдэ. Сами себе проблему создали и героически её решили.
Хинт: а если не транслировать C# → JS, а писать и клиент, и сервер на JS — всё выходит несколько проще.
Хинт: а если не транслировать C# → JS, а писать и клиент, и сервер на JS — всё выходит несколько проще.
Во-первых, JS я не очень хорошо знаю (особенно как на нем разрабатывать на сервере), и он мне не очень нравится. Также не уверен насчет его производительности (особенно что касается небезопасного кода).
Во-вторых, на C# уже был написан код, отвечающий за обработку фотографий.
В-третьих, самое главное, данное решение можно обобщить на Mono и WP (сейчас разрабатывается).
В-четвертых, это просто ново, интересно, красиво и не очень сложно.
Во-вторых, на C# уже был написан код, отвечающий за обработку фотографий.
В-третьих, самое главное, данное решение можно обобщить на Mono и WP (сейчас разрабатывается).
В-четвертых, это просто ново, интересно, красиво и не очень сложно.
По мне так выучить новый язык гораздо интереснее, чем разобраться в тонне странных приблуд для трансляции из одного языка в другой.
JavaScript мне так или иначе пришлось выучить, и я тоже использую его сейчас в чистом виде, т.к. занимаюсь и фронтэндом тоже.
Для фильтров и коллажей же использование описанного подхода мне показалось целесообразней, потому что в них больше именно обработки, а не интерфейса. И почти ничего странного в данных приблудах я не вижу.
Для фильтров и коллажей же использование описанного подхода мне показалось целесообразней, потому что в них больше именно обработки, а не интерфейса. И почти ничего странного в данных приблудах я не вижу.
НЛО прилетело и опубликовало эту надпись здесь
Интереснее. Но это должен быть точно не JS. Ярчайший пример хаотически внебрачно рождённого ЯП.
Если хочется что-нибудь изучить, всегда есть лиспы, хаскелы и ещё несколько таких же красивых и интересных ЯП.
Если хочется что-нибудь изучить, всегда есть лиспы, хаскелы и ещё несколько таких же красивых и интересных ЯП.
НЛО прилетело и опубликовало эту надпись здесь
Для пущей точности Silverlight, все-таки, кроссплатформен, т. к. работает под маком.
Вы видимо unix-подобные ос платформой не считаете? (про mono не стоит говорить, половина плюшек не работает или работает криво)
Насчет криво вы правы однако. Попробовал я ради интереса запустить тестовое WinForms приложение с фильтрами под Mac и Linux. В результате почему-то большинство фильтров просчитывалось неправильно (возможно это связано с различным порядком упаковки r g b a в пикселях, возможно с чем-то другим). Хотя в Win тоже под Mono все работало также как и в обычном .NET, что странно.
Зато в Андроиде почти все работает как надо.
Зато в Андроиде почти все работает как надо.
кроссплатформенный; способность программного обеспечения функционировать в нескольких различных операционных системах или на разных аппаратных платформах.
Сильверлайт (официальная реализация «Майкрософта») работает не только в винде, поэтому попадает под это определение. Да, возможно, жаль, что он не пашет под никсами, но это не делает его от этого не кроссплатформеным (особенно, если вспомнить долю этих самых никсов).
Сильверлайт (официальная реализация «Майкрософта») работает не только в винде, поэтому попадает под это определение. Да, возможно, жаль, что он не пашет под никсами, но это не делает его от этого не кроссплатформеным (особенно, если вспомнить долю этих самых никсов).
Если строго придерживаться этого определения, то софт запускающийся на win7 и win8 тоже кроссплатформенный. Понятие кроссплатформенный, это запускающийся на большинстве современных устройств, ИМХО. Я например хочу использовать приложение как с компьютера на win, так и с ноута на ubuntu, с планшета на android, с телефона на winphone, c ipod'a на ios. Особенно если это web(!!!)-приложение.HTML5 прекрасно себя чувтсвует на всем что я перечислил. И чтоб вы не думали что я против сильверлайта, замечу что это один из профилей моей работы, но я считаю у него все же другая ниша чем интерактивные приложения для широкой публики(корпоративный сегмент сюда не входит). В пример кроссплатформеного приложения, я могу привести keepass.
Много пришлось писать кода отдельно адаптированного под ScriptSharp? Как по мне, то вот этот пример «Поворот и обращение изображения на canvas и Bitmap соответственно» показывает сильную избыточность кода и не помогает решить проблему «один код на сервере и на клиенте».
Ну это как раз таки пример сильно различающегося кода, таких мест не много. При этом везде можно было использовать попиксельную обработку, если бы в .NET не было встроенных функций поворота и обращения.
А основной различающийся код сосредоточен в классах GraphicsNET и GraphicsJS, которые реализуют функции абстрактного класса Graphics для разных платформ. Кроме того, есть дополнительные адаптированный код C# в местах, касающихся интерфейса, потому что он просто не нужен на сервере.
Но например работа с пикселями может быть объединена в один код так (упрощенно):
При этом в JavaScript:
А в .NET:
А основной различающийся код сосредоточен в классах GraphicsNET и GraphicsJS, которые реализуют функции абстрактного класса Graphics для разных платформ. Кроме того, есть дополнительные адаптированный код C# в местах, касающихся интерфейса, потому что он просто не нужен на сервере.
Но например работа с пикселями может быть объединена в один код так (упрощенно):
GraphicsContext context;
try
{
context = thread.GetContext();
#if SCRIPTSHARP
PixelArray data = context.GetPixelArray();
#elif DOTNET
byte* data = context.GetPixelArray();
#endif
int dataLength = context.GetDataLength();
byte[] redColorArray = thread.GetRedColorArray();
byte[] greenColorArray = thread.GetGreenColorArray();
byte[] blueColorArray = thread.GetBlueColorArray();
for (int i = 0; i < dataLength; i += Const.PixelMaskInc)
{
data[i + Const.RedInc] = redColorArray[((byte)data[i + Const.RedInc])];
data[i + Const.GreenInc] = greenColorArray[((byte)data[i + Const.GreenInc])];
data[i + Const.BlueInc] = blueColorArray[((byte)data[i + Const.BlueInc])];
}
}
finally
{
if (context != null)
context.PutImageData();
}
При этом в JavaScript:
RedInc = 0; GreenInc = 1; BlueInc = 2; PixelInc = 4;
А в .NET:
RedInc = 2; GreenInc = 0; BlueInc = 1; PixelInc = 4;
Спасибо за статью. Честно говоря, и не знал о возможности трансляции C# в клиентский javascript. Этакий meteor.js с другой стороны :)
А на C# написан только код обработки графики, остальной фронт-енд все-таки на javascript?
А на C# написан только код обработки графики, остальной фронт-енд все-таки на javascript?
Да, остальной фронтэнд написан на JavaScript, потому что там больше именно интерфейса или кода, не используемого на сервере. Кроме того, для использования jQuery и, например, api google карт нужно писать свои Script# оболочки (для jQuery есть). А в коде обработки графики даже jQuery не используется.
Кстати, вы можете посмотреть на качество сгенерированного JavaScript кода из C# по ссылкам, приведенных в конце статьи (я обновил статью).
Кстати, вы можете посмотреть на качество сгенерированного JavaScript кода из C# по ссылкам, приведенных в конце статьи (я обновил статью).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Универсальный код C# под .NET и JavaScript