Done, for science of course.
It has nothing to do with the allocation of resources. It has to do with how the Qt graphics system works, and how we have to regenerate a lot of data each time the viewport changes. (You can tell it’s related to the data recalculation because resizing the whole file is very fluid; only pan and zoom are slow.)
For most files, this doesn’t matter, but your file falls in the “pathologically bad” category. It’s got a lot of vectors, and they are shaped so that they cannot be simplified much to reduce the data.
We’ll add a small optimization to defer the calculations by 100mS on a pan/zoom for large files since the zoom and pan events tend to come back-to-back-to-back.
@robgrz I think CC uses the GPU for display handling . It certainly handles better.
What aspects are accelerated ?
I would argue that the geometry can be optimized, at least to some degree:
15 nodes
Simplify gets it down to not quite half that:
and overall the file went from almost 13MB:
down to less than 5MB:
which may help a bit until the updated version mentioned is released.
(sent via e-mail)
Thanks again Will, I thought it was going to have a major effect visually but its pretty subtle.
The whole canvas is OpenGL for rendering, but the Qt graphics view is a pretty heavy framework in the middle, and we’ve had to reimplement huge parts of it to make the program function like a normal CAD/design program. If we had it to do again, we’d go straight OpenGL, but on any given day, there are more productive things we can do than remove the last parts of the Qt graphics framework.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.