Я согласен с @timday в том, что вы должны склонить свое расследование к чему-то «реальному», и, как вы предложили в комментарии, вы можете захотеть, чтобы история о выборе между настольным или браузерным приложением.
Это именно то, над чем я сейчас работаю. Мой клиент имеет приложение для визуализации, которое в настоящее время работает на рабочем столе Windows. Типичная сцена для них имеет 500 000 треугольников, множество текстур и прозрачность. В настоящее время их пользователи не хотят устанавливать программу просмотра - они, как правило, работают в корпоративных средах, где системные администраторы контролируют то, что установлено на их компьютерах. И несколько пользователей предпочли бы запускать визуализацию на своих iPad, где зритель не будет работать в любом случае. Поэтому мой клиент хочет знать, решит ли WebGL свои проблемы с платформой, не говоря уже о том, что ни один браузер еще официально не поддерживает WebGL и что ни IE, ни iPad не объявили о какой-либо поддержке.
Помните, что любые тесты, которые вы делаете, относительно бессмысленны, потому что вы измеряете движущуюся цель. Производители браузеров усердно работают над внедрением WebGL и часто обновляют свои бета-версии. Они не только работают над совместным внедрением WebGL, но и должны беспокоиться о проблемах безопасности браузера и общем конвейерном потоке. Это видео рассказывает о некоторых проблемах (и дает представление о том, на что обратить внимание). Кроме того, производительность может варьироваться в зависимости от вашей ОС и графического оборудования.
Как вы указали, когда WebGL работает на графическом оборудовании, он должен работать так же быстро, как приложение для настольного компьютера. Ваши тесты должны попытаться подтвердить это, а затем вы должны попытаться измерить, где производительность теряется в результате нахождения в браузере. У меня такое ощущение, что Javascript сам по себе не является узким местом, просто потому, что Javascript не так много для выполнения (и в наши дни он довольно быстрый). Однако, как описано в конце вышеупомянутого видео, могут быть неэффективности, которые возникают в привязке Javascript-C ++, проверке запросов, управлении потоком и тому подобном. С другой стороны, производители браузеров (по крайней мере, Google) усердно работают над устранением этих недостатков.
Одна из вещей, которые я заметил, это не проблемы с частотой кадров / производительностью (в моем текущем тесте я могу отрисовать 500 000 текстурированных треугольников со скоростью 30 кадров в секунду), но эта частота кадров не кажется очень последовательной, и что кадры кажутся быть сброшенным время от времени. Я подозреваю, но не знаю, имеет ли это отношение к относительно простому способу setInterval() или запуску анимации в Javascript. (Mozilla mozRequestAnimationFrame может быть способом лучше справиться с этим).
Хотя я не знаю, насколько полезен какой-либо из вышеперечисленных пунктов для вашей диссертации, мне кажется, что у вас есть богатая тема, и вы должны делать больше, чем просто придумывать простые тесты. Возможно, вам следует начать с некоторых тестов, сравнить производительность браузера и настольного компьютера, а затем попытаться изучить лучшие практики не только для выбора между браузером и десктопом, но и для написания приложений WebGL.
Существует довольно много фреймворков WebGL. Я попробовал пару, и был очень впечатлен - есть чему поучиться у них. В зависимости от ваших интересов и требований к тезисам, вас может заинтересовать их сравнительный анализ.
Каким бы ни был ваш путь, я подозреваю, что существует большое сообщество потенциальных пользователей WebGL, которые будут испытывать недостаток в информации, которую вы собираетесь исследовать.