Hello Maxime,

thanks for that detailed answer. Much appreciated.
I see, drawing slows down things massively. (3minutes vs. a few seconds)
Bad luck for me then. :)

But it still helped me though, I'm now going for another approach. (The GUI part was just for convenience, so everything is fine)

Thank you and cheers,
Robert

I set up a minimum plugin to demonstrate the problem.
The issue appears in R19, R20, R21.

Find the Gist here: https://gist.github.com/mp5gosu/e5b86b50ef0c9c4657630c31ce26a44e

Please try this plugin with dragging multiple files of different types and folders into the TreeView.

edit: For my initial problem, I was able to avoid the performance bottleneck since on the plugin I'm working, I'm only interested in c4d files and folders that contains them. Not fast enough though, 600 c4d files take up to 30 seconds - 1 minute. This is way too slow for just getting the file paths.

@m_adam Then what is c4d.DRAGTYPE_FILES for? Just for my knowledge and to answer my very first question. :)

Hi Maxime,

thanks for joining in. :)
@m_adam said in TreeView: c4d.DRAGTYPE_FILES:

Hi @mp5gosu what's your final goal? Be able to drag an external file to a TreeView?

Yes.

If yes then DRAGTYPE_FILENAME_OTHER should be used.

This is my current solution

As @zipit pointed AcceptDragObject should only tell if the dragged object is acceptable or not. Since it's called very very frequently during the drag process the slow down can come from there.

Yes, this is correct. Already reverted, same issue.

InsertObject should be used to insert an object only when the click of the drag process released.

Even with using InsertObject, problem remains - still low performance. See my post above.

Now regarding the implementation by itself, it's true that some analysis of the file is done so you know if the dragged file is an image (DRAGTYPE_FILENAME_IMAGE), or a scene aka something that could be opened in C4D so a c4d file or fbx (DRAGTYPE_FILENAME_SCENE) or anything else (DRAGTYPE_FILENAME_OTHER).

Thanks for the insights. This confirms my observations.

Normally it shouldn't be an issue since it uses the SceneLoader/BitmapLoader::Identify func to operation (so reading usually only the first bytes, usually 1024). So maybe you have a custom SceneLoader/BitmapLoader that does read more than what he needs and this why you see a slowdown however here I'm not able to see any slowdown even running C4D in debug mode.

Maybe you can share your Code/File.

Will do later, when I'm home.

Cheers,
Maxime.

Cheeers,
Robert. ;)

@zipit said in TreeView: c4d.DRAGTYPE_FILES:

You are actually not doing what the method is supposed to do. You always return False for the drag operation.

That shouldn't matter, because no copy should be made.
The docs say bool: True if copying is allowed to this position, otherwise False. - if I get that right, this is ok.
c4d.NOTOK is here to prevent default behaviour when dragging objects into Cinema 4D, i.e. opening a Cinema 4D scene or images and so on.

You also modify the root from within AcceptDragObject(), but the place to actually do that is InsertObject(). It seems likely that this does not matter for trees that

Ah yes, you are right. When I started implementing the TreeView I actually cerated and inserted the object via InsertObject as usual.
While trying various thing, I found it easier to simply create it here - but yes - you are right. Will revert it. Nice catch.

edit: Just noticed the following:
What ever file I drag into the TreeView, Cinema indeed tries to identify the type.
I observed the debugger output coming up with the following messages:
BaseSound::Identify Error: mediasessionwrongtype [hierarchy.cpp(141)]
majorType: MFMediaType_Audio, subType: MFAudioFormat_MP3, 22050, 1, 8000, 16
BaseSound::Identify Error: Image file:///E:/Downloads/desktop.ini is not of a supported type. [neighborex.cpp(81)]

And some more. Those errors are raised for any file that i unknown to Cinema 4D.
So I still suspect, that C4D tries to identify every filetype I drarg into. That would also explain the performance loss.

edit #2: After some tests, I am now sure that there is some parsing on files. Files that are 0 bytes or known by C4D get added almost in no time.
Garbage or broken files (e.g. bogus.c4d - a renamed text file that with filesize > 0) are analyzed.

Hi @zipit,

thank you for the response.
I'm aware of how AcceptDragObject works and probably should have given a bit more detail. (Was a bit late yesterday, hence the short post)

The current code looks like this:
Note: root is actually a simple list that holds objects of type ListItem.

class ListItem looks like this (stripped down version):

class ListItem:
    def __init__(self, filename):
        self.__filename = filename

    @property
    def filename(self):
        return self.__filename

    def __repr__(self):
        return str(self)

    def __str__(self):
        return self.__filename

    def __eq__(self, other):
        return self.__filename == other

The part in TreeViewFunctions:

def AcceptDragObject(self, root, userdata, obj, dragtype, dragobject):
        if dragtype == c4d.DRAGTYPE_FILENAME_OTHER or dragtype == c4d.DRAGTYPE_FILENAME_SCENE:
            filename = path.abspath(path.realpath(dragobject))
            if filename not in root:
                if path.exists(filename.decode("utf8")):
                    root.append(ListItem(filename))
            return c4d.INSERT_AFTER | c4d.INSERT_BEFORE, False

        return c4d.NOTOK, False

As stated in the initial post, it does work like intended but for "foreign" files (Windows, let it be .exe, .dll, . json, .txt, et al) it seems like Cinema analyzes the data chunk of the first bytes of the file contents to distinguish file types (scenes, images and so on). (this is just a assumption)

So much for the background info.
As for the initial question:
In my example dragtype is set to c4d.DRAGTYPE_FILENAME_OTHER since I want to be able to react to certain filetypes and folders.
The docs however do have the flag DRAGTYPE_FILES which - I hoped - would speedup the process by not checking the data chunks. But no luck, it seems like the flag does nothing or works only on different OS.

My question may be a bit misleading - I was hoping for a performance gain since it has to work with thousands of files. ;)

Cheers,
Robert

Hello Café,

what is DRAGTYPE_FILES supposed to do?
The documentation states: Files. The data is a string with the filename.
However, using this flag only has no effect here. I cannot drag anything into the TreeView.

Using DRAGTYPE_FILENAME_OTHER works, but it's horribly slow. It seems like that any file is analyzed to a certain extent.
.c4d files get added very quickly other file types massively lack performance.

Is this a known issue or limitation? Otherwise, I'll file a BL report. ;)

Do you use the same major/minor version on the other computer?

Hello. In addition to @zipit's excellent answer, you might consider also implementing a Message Plugin and react to CoreMessages, sent via c4d.SpecialEventAdd()

@zipit:

May I ask for practical examples on where you have seen this behavior?

There are actually some tags with GUI interaction. The MographCache Tag for example.

You are calling the Dialog via DLG_TYPE_MODAL. So the Dialog is blocking the main thread until you close it.
Try opening the dialog with DLG_TYPE_ASYNC.

@ilad Well, it's not limited to non-animated objects. As @r_gigante posted, you're actually modifying the points and the matrix. Both operations can also be achieved manually. So, no difference if animated or not.

The only thing you have to keep in mind when modifying animated objects is to make sure, all keys containing Matrix/PLA data have to be handled as well.