-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
HYDRA-598 : Merge viewport information interface #4
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi, thanks for doing this! I know I've put a lot of comments, but a lot of them are nits, minor things or questions to help me understand things a little better.
lib/flowViewport/API/interfacesImp/fvpInformationInterfaceImp.cpp
Outdated
Show resolved
Hide resolved
lib/flowViewport/API/interfacesImp/fvpInformationInterfaceImp.h
Outdated
Show resolved
Hide resolved
lib/flowViewport/API/interfacesImp/fvpInformationInterfaceImp.h
Outdated
Show resolved
Hide resolved
lib/flowViewport/API/interfacesImp/fvpInformationInterfaceImp.cpp
Outdated
Show resolved
Hide resolved
lib/flowViewport/API/interfacesImp/fvpInformationInterfaceImp.cpp
Outdated
Show resolved
Hide resolved
plugin/mayaHydraSceneBrowserTest/mayaHydraSceneBrowserTestCmd.cpp
Outdated
Show resolved
Hide resolved
} | ||
} | ||
|
||
delete (*findResult); //delete the ViewportInformationAndSceneIndicesPerViewportData* |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm worried about manually managing the ViewportInformationAndSceneIndicesPerViewportData : could we store the ViewportInformationAndSceneIndicesPerViewportData by value, or at least with smart pointers to reduce the risk of running into memory management issues?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I started to store them by value as you suggested but there is still the ViewportInformation pointer to manage (new/delete) which is inside this class so we would still have to manage some memory.
So is this something you still want ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also since this is data per viewport and is not shared by any other class I think it should be manageable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I haven't managed to make it work with with unique_ptrs (there is a copy I can't find somewhere, but the error message only indicates lines in the standard library headers), but it does work with shared_ptrs. I'm not sure if the overhead would be a problem or not, but either ways, I think as long as we stick to the one new
and the one delete
we currently have, this should be fine as it's isolated in the implementation and very symmetrical.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(Grouping this conversation with this comment)
So after taking a closer look, the situation with ViewportInformation
objects is quite similar, as like you said, those are also manually managed, with the exception that objects of that class are expected to be manually created outside of the Flow Viewport Toolkit, and their ownership then transferred to the Flow Viewport Toolkit. I feel like this should also be solvable with unique_ptrs.
That being said, if we can't get smart pointers to work, then I think we should at least explicitly document that the AddViewportInformation
method will assume ownership of the ViewportInformation
object it receives, so that users know not to have the object they pass in be deleted. And to make the method signature a bit more explicit, maybe we can also make it receive a raw pointer rather than a const reference?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
AddViewportInformation is not called by users, but by maya hydra only. But you're right, I changed the method signature and added more comments about the ownership.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Explicit calls to delete are a maintenance burden and are not exception safe. They violate this C++ core guideline:
http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rr-newdelete
If we're still using an explicit call to delete (and it looks like we are), we should try to change the code to avoid it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok, I will try to find a way to avoid delete.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am using a std::set with copies in it instead of arrays, the class to copy is not heavy and this set will have the size of the number of viewports in maya.
lib/flowViewport/API/interfacesImp/fvpInformationInterfaceImp.cpp
Outdated
Show resolved
Hide resolved
} | ||
} | ||
|
||
delete (*findResult); //delete the ViewportInformationAndSceneIndicesPerViewportData* |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Explicit calls to delete are a maintenance burden and are not exception safe. They violate this C++ core guideline:
http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rr-newdelete
If we're still using an explicit call to delete (and it looks like we are), we should try to change the code to avoid it.
lib/flowViewport/API/interfacesImp/fvpInformationInterfaceImp.cpp
Outdated
Show resolved
Hide resolved
{ | ||
std::lock_guard<std::mutex> lock(_viewportInformationClient_mutex); | ||
|
||
InformationClient* clientNonConst = const_cast<InformationClient*>(&client); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This feels very awkward in terms of ownership. We shouldn't be storing a pointer to something that is conceptually passed by value, because the argument object may disappear if it goes out of scope. I think this should be changed.
|
||
PXR_NAMESPACE_OPEN_SCOPE | ||
|
||
using SceneIndicesVector = std::vector<HdSceneIndexBasePtr>; | ||
using SceneIndicesVector = std::vector<HdSceneIndexBasePtr>;//Be careful, these are not not Ref counted. Elements could become dangling |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If it's a maintenance burden, then I would change to using HdSceneIndexBaseRefPtr.
...PI/perViewportSceneIndicesData/fvpViewportInformationAndSceneIndicesPerViewportDataManager.h
Outdated
Show resolved
Hide resolved
...PI/perViewportSceneIndicesData/fvpViewportInformationAndSceneIndicesPerViewportDataManager.h
Outdated
Show resolved
Hide resolved
{ | ||
//The viewport info is own by this class | ||
InformationInterfaceImp::Get().SceneIndexRemoved(_viewportInformation); | ||
delete &_viewportInformation; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Again, an explicit delete violates
http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rr-newdelete
There should have only 1 remaining problem about the lifetime management which we are discussing offline. |
...wport/API/perViewportSceneIndicesData/fvpViewportInformationAndSceneIndicesPerViewportData.h
Show resolved
Hide resolved
…account the shared scene/render/index we use for all viewports
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the tests!
No description provided.