Skip to content
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

Merged
merged 13 commits into from
Nov 21, 2023

Conversation

lanierd-adsk
Copy link
Collaborator

No description provided.

@lanierd-adsk lanierd-adsk self-assigned this Nov 9, 2023
@lanierd-adsk lanierd-adsk marked this pull request as ready for review November 10, 2023 13:34
@lanierd-adsk
Copy link
Collaborator Author

FYI : @lilike-adsk @roopavr-adsk @ppt-adsk

Copy link
Collaborator

@debloip-adsk debloip-adsk left a 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.

plugin/mayaHydraSceneBrowser/mayaHydraSceneBrowser.cpp Outdated Show resolved Hide resolved
lib/mayaHydra/mayaPlugin/renderOverride.cpp Outdated Show resolved Hide resolved
lib/flowViewport/sceneIndex/fvpRenderIndexProxy.cpp Outdated Show resolved Hide resolved
}
}

delete (*findResult); //delete the ViewportInformationAndSceneIndicesPerViewportData*
Copy link
Collaborator

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?

Copy link
Collaborator Author

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 ?

Copy link
Collaborator Author

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.

Copy link
Collaborator

@debloip-adsk debloip-adsk Nov 14, 2023

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.

Copy link
Collaborator

@debloip-adsk debloip-adsk Nov 14, 2023

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?

Copy link
Collaborator Author

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.

Copy link
Collaborator

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.

Copy link
Collaborator Author

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.

Copy link
Collaborator Author

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.

@lanierd-adsk lanierd-adsk removed their assignment Nov 15, 2023
}
}

delete (*findResult); //delete the ViewportInformationAndSceneIndicesPerViewportData*
Copy link
Collaborator

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/mayaHydra/hydraExtensions/mayaHydraSceneProducer.cpp Outdated Show resolved Hide resolved
{
std::lock_guard<std::mutex> lock(_viewportInformationClient_mutex);

InformationClient* clientNonConst = const_cast<InformationClient*>(&client);
Copy link
Collaborator

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
Copy link
Collaborator

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.

{
//The viewport info is own by this class
InformationInterfaceImp::Get().SceneIndexRemoved(_viewportInformation);
delete &_viewportInformation;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lib/mayaHydra/mayaPlugin/renderOverride.cpp Outdated Show resolved Hide resolved
@lanierd-adsk
Copy link
Collaborator Author

There should have only 1 remaining problem about the lifetime management which we are discussing offline.

…account the shared scene/render/index we use for all viewports
Copy link
Collaborator

@ppt-adsk ppt-adsk left a 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!

@lanierd-adsk lanierd-adsk added the ready-for-merge Development process is finished, PR is ready for merge label Nov 21, 2023
@roopavr-adsk roopavr-adsk merged commit 9922683 into dev Nov 21, 2023
9 checks passed
@roopavr-adsk roopavr-adsk deleted the lanierd/HYDRA-598 branch November 21, 2023 16:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
fvp-toolkit Flow Viewport Toolkit ready-for-merge Development process is finished, PR is ready for merge
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants