You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@jan-cosmigo, the Fake plug-in is a proof-of-concept File I/O plug-in which fakes exporting images to the .fake format (doesn't actually save anything) as an excuse to log all the DLL calls that PMNG executes to the plug-in, both at initialization time as well as when exporting.
NOTE — You'll always find the pre-compiled DLL of the latest version on our shared GDrive folder, which is automatically deployed when I build the final DLL.
This plug-in has helped me get a better insight about how the File I/O interface actually works in real case scenarios, and provided me with the order in which DLL functions are called.
But it also shows some strange things, i.e. that PMNG seems to call some initialization functions more than once. I'm not sure why this happens, and whether it's caused by the fact that the plug-in causes a slight delay in its responses due to the visual logging, or whether that's the way the interface is supposed to work.
In any case, I though it was worth providing you with the latest logs, in case these redundant calls are not supposed to occur, and also because I'm curious about them since I've noticed that their occurrence is not fixed and might change depending on how many plug-ins are present in the plugins/ folder.
Initialization Log
Here's the full log from when the DLL is attached to PMNG's process up to the end of all initialization calls:
As you can see, getFileBoxDescription() is called multiple times (10 times!), and so is getFileTypeId() (29 times), as well as others (but not all).
I was wondering whether this has to do with the fact that PMNG has multiple File I/O interfaces (image import/export, animation import/export, palette import/export, and so on), which would explain why these are called multiple times — although it would make more sense to call them once and store the returned values, or memoize these calls to avoid redundancy (I've noticed that when there are more than 3 plugins PMNG startup can get quite slow).
Image Export Log
And here's the log from a simulated image export (Save Image As » "FAKE"):
Of all these redundant calls, only the double call to setFilename() might actually affect plugin developers, depending on how the call is handled — as you can see from the second call in the above log, the FAKE plugin explicitly checks if the filename being passed is the same as the previous one, a check I introduced when noticing that the function might be called multiple times during a single image export operation.
The rest of the redundant calls are not really a concern to developers, since they are just plugin-info retrieval calls (which plugins should blindly obey to).
I was just curious on why all these redundant calls are there — especially since I'm planning to work an a File I/O simulator, to simplify testing plugins during development (i.e. not having to close and launch PMNG at every code edit, but just for final testing).
The text was updated successfully, but these errors were encountered:
@jan-cosmigo, the Fake plug-in is a proof-of-concept File I/O plug-in which fakes exporting images to the
.fake
format (doesn't actually save anything) as an excuse to log all the DLL calls that PMNG executes to the plug-in, both at initialization time as well as when exporting.This plug-in has helped me get a better insight about how the File I/O interface actually works in real case scenarios, and provided me with the order in which DLL functions are called.
But it also shows some strange things, i.e. that PMNG seems to call some initialization functions more than once. I'm not sure why this happens, and whether it's caused by the fact that the plug-in causes a slight delay in its responses due to the visual logging, or whether that's the way the interface is supposed to work.
In any case, I though it was worth providing you with the latest logs, in case these redundant calls are not supposed to occur, and also because I'm curious about them since I've noticed that their occurrence is not fixed and might change depending on how many plug-ins are present in the
plugins/
folder.Initialization Log
Here's the full log from when the DLL is attached to PMNG's process up to the end of all initialization calls:
As you can see,
getFileBoxDescription()
is called multiple times (10 times!), and so isgetFileTypeId()
(29 times), as well as others (but not all).I was wondering whether this has to do with the fact that PMNG has multiple File I/O interfaces (image import/export, animation import/export, palette import/export, and so on), which would explain why these are called multiple times — although it would make more sense to call them once and store the returned values, or memoize these calls to avoid redundancy (I've noticed that when there are more than 3 plugins PMNG startup can get quite slow).
Image Export Log
And here's the log from a simulated image export (Save Image As » "FAKE"):
... up to when I chose the "FAKE" format in the PMNG export dialog.
(again, you can see the duplicate calls)
And then, after having confirmed the "FAKE" format and the next PMNG's options pop-up dialog (pixel scale, effects, etc.):
Of all these redundant calls, only the double call to
setFilename()
might actually affect plugin developers, depending on how the call is handled — as you can see from the second call in the above log, the FAKE plugin explicitly checks if the filename being passed is the same as the previous one, a check I introduced when noticing that the function might be called multiple times during a single image export operation.The rest of the redundant calls are not really a concern to developers, since they are just plugin-info retrieval calls (which plugins should blindly obey to).
I was just curious on why all these redundant calls are there — especially since I'm planning to work an a File I/O simulator, to simplify testing plugins during development (i.e. not having to close and launch PMNG at every code edit, but just for final testing).
The text was updated successfully, but these errors were encountered: