Комментарии 20
НЛО прилетело и опубликовало эту надпись здесь
Анимация перелистывания не нужна.
Ее можно отключить.
Во время угнетающего флат-дизайна везде и всюду — даже такая мелочь как текстура бумаги и уж тем более анимация перелистывания страниц привносит лучик добра в этот беспощадный мир.
Имхо.
Имхо.
Тут в соседнем посте пеняют на еБуки что они слишком медленно «переворачивают» страницу. А тут анимация, которая время просто крадёт (а могло б и заняться чем-нибудь полезным, батарейку сберечь, к примеру). Мне тут вроде понравилась одна программа для чтения, но в ней все анимации невозможно отключить, точнее можно, но только переворачивание страницы если книга в каком-нить читальном формате. А открытие/закрытие книги и «переворачивание» страницы в pdf — не отключается и жутко бесит, так что пока ищу.
Ну естественно требуются визуальные настройки в конфигах приложения — это очевидно и никто не спорит. Просто я похвалил автора за то, что он не ведётся на волне моды, а просто делает красивое приложение.
И не думаю, что простая анимация будет настолько требовательна к ресурсам. Лично у меня (на андроиде правда) больше всего кушает связь с сетью и экран, а всякие игрушки (которые в теории должны есть больше всех) где-то месте на 6ом+ в статистике использования аккумулятора.
И не думаю, что простая анимация будет настолько требовательна к ресурсам. Лично у меня (на андроиде правда) больше всего кушает связь с сетью и экран, а всякие игрушки (которые в теории должны есть больше всех) где-то месте на 6ом+ в статистике использования аккумулятора.
Полностью согласен. Только время тратится на этот эффект и мощь проца. Но пост, полагаю, не об этом.
К сожалению, не все так считают. Есть много пользователей, которые гневно жалуются, что им нужно больше анимаций перелистывания.
m_d3dContext->OMSetRenderTargets(0, nullptr, nullptr);
m_renderTargetView = nullptr;
m_depthStencilView = nullptr;Ну и release контекста:
m_d3dContext = nullptr;Разумеется. И контекст и само устройство надо удалять.
Вообще все DirectX интерфейсы надо удалять. Но просто присвоить nullptr для ComPtr<?> может быть не достаточно.
Вообще все DirectX интерфейсы надо удалять. Но просто присвоить nullptr для ComPtr<?> может быть не достаточно.
Я даже вот так делал (и сейчас делаю):
Не помогло.
ComPtr<IDXGIDevice3> dxgiDevice;
m_d3dDevice.As(&dxgiDevice);
dxgiDevice->Trim();
m_dxgiOutput = nullptr;
m_d3dContext = nullptr;
m_d3dDevice = nullptr;
Не помогло.
Странно все это. А графический дебаггер что говорит по этому поводу? VS2013 умеет считать AddRef/Release-ы.
Графический дебаггер на эмуляторе не запускается. А Performance and Diagnostics говорит что при создании буфера глубины и рендер таргета выделяется память, но не освобождается.
void BaseSwapChainPanel::CreateRenderTargetView()
{
// Create a render target view of the swap chain back buffer.
ComPtr<ID3D11Texture2D> backBuffer;
DX::ThrowIfFailed(m_swapChain->GetBuffer(0, IID_PPV_ARGS(&backBuffer)));
// Once the swap chain is created, create a render target view. This will
// allow Direct3D to render graphics to the window.
DX::ThrowIfFailed(m_d3dDevice->CreateRenderTargetView(backBuffer.Get(), nullptr, &m_renderTargetView));
}
void BaseSwapChainPanel::CreateDepthStencilView()
{
// Create a depth stencil view for use with 3D rendering if needed.
ComPtr<ID3D11Texture2D> depthStencil;
CD3D11_TEXTURE2D_DESC depthStencilDesc(
DXGI_FORMAT_D24_UNORM_S8_UINT,
static_cast<UINT>(m_renderTargetWidth),
static_cast<UINT>(m_renderTargetHeight),
1, // This depth stencil view has only one texture.
1, // Use a single mipmap level.
D3D11_BIND_DEPTH_STENCIL
);
DX::ThrowIfFailed(m_d3dDevice->CreateTexture2D(&depthStencilDesc, nullptr, &depthStencil));
auto viewDesc = CD3D11_DEPTH_STENCIL_VIEW_DESC(D3D11_DSV_DIMENSION_TEXTURE2D);
DX::ThrowIfFailed(m_d3dDevice->CreateDepthStencilView(depthStencil.Get(), &viewDesc, &m_depthStencilView));
}
НЛО прилетело и опубликовало эту надпись здесь
Я не писал для WP 8.1 DX, но когда писал рендер маршрута для WP 8 DX. Специально озадачился освобождением ресурсов, но наткнулся в документации на указание не трогать ресурсы DX упакованные в ComPtr<>, рефкаунтеры мол сами отработают. Проверил действительно утечек не было из за этого, хотя ресурсы создавались в большом количестве. Но с другой стороны я на каждом цикле рендера, чистил биндинги аля «m_d3dContext->OMSetRenderTargets(0, nullptr, nullptr);».
А с учетом того, что профайлер в WP 8 полное КЮ и отследить им, что то кроме факта утечки проблематично, считаю что мне крупно повезло, что я не встретился с такими проблемами!
А с учетом того, что профайлер в WP 8 полное КЮ и отследить им, что то кроме факта утечки проблематично, считаю что мне крупно повезло, что я не встретился с такими проблемами!
Постоянных утечек в процессе чтения книги и тут не было. В процессе, пока крутится основной цикл рендеринга — все хорошо. Память утекала при пере-инициализации. Т.е. пользователь свернул/развернул приложение. Закрыл/открыл книгу.
На счет ComPtr<>: можно обойтись без его, но тогда надо самому вызывать Release(). А для того, чтобы отработали рефкаунтеры, надо их как-то уменьшать. Для этого и присваивается полям nullptr.
В том случае если освобождение ресурсов происходит перед убиением процесса, утечки незаметны. Но в WP8.1 процесс полностью не убивается и на 3-4 сворачивании/разворачивании проблема становится критической.
На счет ComPtr<>: можно обойтись без его, но тогда надо самому вызывать Release(). А для того, чтобы отработали рефкаунтеры, надо их как-то уменьшать. Для этого и присваивается полям nullptr.
В том случае если освобождение ресурсов происходит перед убиением процесса, утечки незаметны. Но в WP8.1 процесс полностью не убивается и на 3-4 сворачивании/разворачивании проблема становится критической.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
О том, как память текла, а я не мог понять, почему