я пошел другим путем, путем написания собственного велосипеда
добавил метод расширение для Observable аля safeSubscribe(this, () => {}) и в качестве первого параметра принимаю ссылку на компонент наследующий DisposableСomponent и таким образом при уничтожении компонента могу принудительно произвести отписку от для всех подписчиков

или Kendo UI до кучи

в целом соглашусь
вот только если просто последовательно закрашивать экран 320 х 200 сплошным текстом, то это уже будут сотни тысяч операций, ни как не десятки

он говорит об «порядка (320×200)² операций»
в моем случае их в 2 раза меньше, как сумма 1..n, где n = 320х200
я уже не помню как посчитать такты, забылось, но мне кажется что на ассемблере при прямой работе с видеопамятью, не так страшен черт

от 1 до 63999

еще как отлчается
это не тупой перебор точек на предмет закрашено или нет
а ровно X * Y случайных чисел, т.е 320×200 операций, не более
хотя смотря что вы понимаете под операцией
пример:
2 х 2
случайное число
2 (0..3) — красим x=0, y=1
2 (0..2) — красим x=1, y=1 (пропускаем x=0, y=1 т.к. оно уже закрашено)
0 (0..1) — красим x=0, y=0
0 (0..0) — красим x=1, y=1 (опять же, первый закрашен, пропускаем)
итого 4 операции, и не 16

когда мне задали такую задачку, по принципу — а как бы ты сделал, мне пришла идея, как мне кажется куда проще, — если представить экран Х на Y в виде одномерного массива (по сути это и есть кусок видео памяти), то зная что всего Z = x * Y точек, мы генерируем случайное числ от 0 до Z — 1 = A и начинаем бегать по массиву (видеопамяти) и искать не закрашенную точку, при этом если нашли такую считаем сколько раз, пока не получим число = A, и красим ее
далее Z = Z — 1 и повторяем процедуру
недостаток только в том что нам нужно каждый раз читать видеопамять на предмет не закрашенной точки N раз, где N [1… W*H]

я не знаю вашу архитектуру, «вы жираф вам виднее», сейчас то панель отдельно прекрасно работает, на вид тут лишь вопрос именно встраивания панели в основное окно, в остальном вопросы chromiuma
ну это мое субъективное видение

если память не изменяет, Вы тоже самое писали почти 2 месяца назад
что же, ждем, надеемся

я смотрю что про встраивание developer tools в окно браузера уже ни кто и не вспоминает :)
надеюсь до конца 2017 года будет реализовано

ИМХО настоящий программист и хороший менеджер, — два взаимоисключающих понятия

просто из любопытства, есть какие-то сложности или просто приоритеты другие?
может стоило бы рассказать сообществу о столь нужной и в тоже время не достижимой цели

Он работает внутри процесса, и это большая проблема, потому что год 2016-й, а Visual Studio — всё ещё 32-битный процесс

возможно задам глупый вопрос, а почему не вынести свои потоки в отдельный процесс и организовать межпроцессное взаимодействие?

1. показывать исходники, например ts или sass
3. речь об developer tools, встроенные средства отладки, ваш скрин с firebug

ох уж эти ограничения на портале, случайно нажал не ту клавишу и не могу закончить мысль )

собственно список (речь об 52 версии, Developer Edition):
— пока не работает опция show original sources
— по сравнению с chrome сильно тормозит во время обработки/загрузки списка ресурсов (большой проект)
— во вкладке Сеть нет опции preserve log (нашел как в настройках ее включить, но каждый раз туда лазить не по феншую)

давно присматриваю за развитием встроенных средств, поскольку FireBug мне всегда не нравился своей тяжеловесностью
так уж сложилось, сравниваю с фичами ком использую в Chrome
лично мне не хватает (на вскидку):
—

а в бета версии когда можно будет «пощупать»?
отличный браузер, все нравится, вот за исключением этого недостатка

я видимо что-то пропустил, Visual Studio 2015 и Visual Studio 15 не одно и то же?