Hi,

So I've decided to dust off my C++ skills and did a bit of a deeper dive into 
the FastCgi / HttpHandler for Mapguide. I'm trying to find new, more efficient 
ways to develop applications with Mapguide and making it a part of more complex 
systems, such as having a gRPC interface. I'm looking into using .NET Core with 
version 8 of the framework. I believe there's a lot of cool stuff we could make 
Mapguide do, but I am hitting a bit of a performance wall on some 
functionalities, primarily with map draws.

The biggest challenge I'm encountering is that it appears some functionalities 
are hidden away behind the INTERNAL_API flag, that I believe just hides them 
from SWIG, but they still get rolled up in the C++ binaries. I did a quick 
check on MgPlatformBase.dll and you do get functions like 
MgMapBase::SetViewCenter and MgMapBase::SetViewScale. Both of these calls are 
used by the mapagent.fcgi whenever you're doing a GetDynamicMapOverlayImage.

There's a few more of those functions that gets hidden away like that and I 
feel it makes hitting better performance harder when trying to use the exposed 
APIs. It also makes some functionalities impossible to do, such as just drawing 
an image with the current map selection.

In keeping with my GetDynamicMapOverlayImage, if you want to do the same in C#, 
you need to use RenderMap method on the MgRenderingService with all the exposed 
options, versus duplicating what the FastCgi is doing and calling up 
RenderDynamicOverlay. We just can't do the same in C# and it does appear to 
cost 30% of performance. This is napkin benchmaking notes, I'd love to get more 
concrete numbers but it's difficult when comparing apples and oranges.

So my question is, is there an historical reasoning behind hiding away those 
APIs? It feels more like an Autodesk thing than an API design thing. Although I 
will admit I might be missing the reason to hide away SetViewCenter. Maybe it's 
to prevent devs from shooting themselves in the foot.

Would having a "use at your own risk" version of the API with no hidden away to 
C#, Java and PHP methods be something useful for the community? With all the 
work Jackie put in moving to a standard version of SWIG in 4.0, maybe it's even 
something someone with basic knowledge of C++ like myself could get done?

Cheers,
Ben
_______________________________________________
mapguide-users mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/mapguide-users

Reply via email to