[vtkusers] Slow text rendering with vtkCornerAnnotation and big windows
Marc Ruiz Altisent
marc.ruiz+vtk at gmail.com
Wed Jul 29 08:27:14 EDT 2015
Thank you David. I have made the bug report:
http://www.vtk.org/Bug/view.php?id=15603
2015-07-28 18:29 GMT+02:00 David Lonie <david.lonie at kitware.com>:
> Hi Marc,
>
> On Tue, Jul 28, 2015 at 10:19 AM, Marc Ruiz Altisent <
> marc.ruiz+vtk at gmail.com> wrote:
>
>> Hi, I'm the developer of a medical viewer that uses vtkCornerAnnotation
>> to display image-related information in the corners of the window. I have
>> found that updating the text for each frame is slow when the window is very
>> big, like for example in a 5 MPixel medical display.
>>
>> Previously we used the vtkRenderingFreeTypeOpenGL module and annotation
>> updates were instantaneous no matter the window size, but it doesn't
>> support UTF-8, so we decided to not use it anymore.
>>
>> Now, with the default implementation in the vtkRenderingFreeType module,
>> when the window is very big the updates take a considerable amount of time,
>> to the point of making the application very laggy when scrolling through
>> images. I have tried to limit the text size to a small number, but even
>> then with a big window text rendering is slow and with a small window it's
>> fast, so it's not directly related to text size. I don't know exactly what
>> is causing the slowness, but according to profiling tests, the bottleneck
>> is the vtkFreeTypeTools::RenderCharacter() method.
>>
>> Could the performance of text rendering be improved? Currently I could
>> revert back to using the vtkRenderingFreeTypeOpenGL module, even with its
>> limitations, but since it will disappear in VTK 6.3 this would just be a
>> short-term workaround.
>>
>
> I suspect that vtkFreeTypeTools::RenderCharacter is not a bottleneck,
> though it would be eating up a lot of time in a profiler as it's where most
> of the heavy-lifting is done during text rendering.
>
> After taking a quick skim through the code, the more likely problem is in
> vtkCornerAnnotation::RenderOpaqueGeometry, which has the following loops:
>
> while (... /*annotation size is too small*/ && fontSize < 100)
>
> {
>
> fontSize++;
>
> for (int i = 0; i < NumTextPositions; i++)
>
> {
>
> this->TextMapper[i]->GetTextProperty()->SetFontSize(fontSize);
>
> this->TextMapper[i]->GetSize(viewport, tempi + i * 2);
>
> }
>
> /* Recompute dimensions of annotation */
>
> }
>
>
> /* Followed by the same thing, but decrease font size to fit */
>
>
> So it basically renders the text repeatedly, attempting to fit it to a
> box. Combining a high density display with the new DPI support in VTK and
> repeatedly rendering to fit a box like this will likely eat up a lot of
> time and thrash memory pretty hard.
>
> It looks like it's currently not possible to 'seed' the fontsize via the
> vtkCornerAnnotation API -- it just grabs the default font size from an
> unmodified vtkTextProperty object (line 460) as a starting point.
>
> Can you file a bug for this? At the very least the initial fontsize should
> be able to be set, and at best this class should be refactored to use newer
> text renderering APIs like vtkTextRenderer::GetBoundingBox, which won't
> actually generate a texture but just compute the dimensions of the
> resulting image.
>
> Thanks,
> Dave
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtkusers/attachments/20150729/08f57ae8/attachment.html>
More information about the vtkusers
mailing list