My name is Markus and I develop GEOlayers, a CEP Extension for After Effects to design and animate maps. I just tried out UXP in XD to learn more about the platform and its possibilities. Hope here is the right place for feedback. Unfortunately it didn’t work out well for my usecase yet. UXP lacks a lot of browser functionality and therefore is not compatible with a lot of 3rd party libs. An example: There is a few web map viewers out there. Mapbox gl js is one of the most powerful open source tool for mapping applications out there. Is it possible in some way to run it within a UXP panel? Are there any workarounds? If not it will make it impossible to migrate GEOlayers to UXP as CEP dies.
Thanks and best regards,
Hi Markus, and welcome to the forums.
When it comes to UXP, it’s important to recognize that it isn’t a browser. While it does pretend to be one in a lot of cases, it isn’t, and never will be. A full web browser is much slower, consumes a lot of memory, etc., and as such, UXP offers a much smaller API set that uses lower level rendering components (rather than web controls) to offer improved performance.
Because UXP isn’t a browser, there are a lot of third party libraries that won’t work out of the box. From the sounds of it, the one you’re referring to uses WebGL, which UXP doesn’t currently support. We are looking at options for 3D rendering – the current frontrunner would be support for WebGPU when it stabilizes.
And that’s the important thing to note here: sometimes it’s going to take a novel approach to get similar functionality in UXP. For maps, for example, SVG might work. Or should we support WebGPU, using a library that utilizes that method of 3D rendering might work. UXP is not going to be a 1:1 map from CEP.
It’s also worth noting that CEP isn’t going away quickly and UXP as present in XD is not the final version. We will continue to mature and improve the platform over the coming years. But it won’t be quite the same as a browser environment, so it’s likely there will need to be novel solutions for certain use cases.
Hopefully that helps, and we do appreciate your feedback. Right now, UXP is likely too immature for your particular use case (short of having a helper app render the maps), but that doesn’t mean it will be so in the future, so I hope you’ll keep an eye out as we continue to mature and grow the platform. DVA apps are on our radar, but it’s still too early to know what willl be available in the first release of extensibility in those apps.
Hi Kerri, thanks for your reply. I understand what you’re following with UXP and see the benefits of a lightweight implementation. On the other hand I personally think it is a pity that we won’t even have the option to use software (libs) developed for the web. That was the power of CEP. I think single extension/plugin devs wont’t be able to adapt complex libs made by many contributers over many years and even keep up with updates. And the UXP dev ecosystem will be too small to keep up with regular web development. Just my opinion though. I’ll keep an eye on how UXP evolves. Is there a apprx. timeline when UXP comes to AE?
Again, thanks for your insights.
Your plugin looks very nice. We aim to make UXP capable to supporting the development of similar plugins.
Our goal with UXP is to offer as much compatibility with the web as possible - even if our implementation is very thin and lightweight - including supporting a web view in the future for cases that we won’t ever support.
WebGL in particular was something that we have integrated at some point, but then decided to wait for the standard to stabilize (WebGPU) before building something that is being deprecated as it’s based on OpenGL that seems to be on its way out from all OSes.
Kerry - what is our plan for web views?
Thanks for your reply! I don’t get the idea of the web views… As I understand it, it would use the UXP behave-almost-like-a-browser thing to render a website right? So therefore the same problems would occur right? One could only render the same HTML subset which ends up in quite a lot of websites would’t work. Or am I getting things wrong here? Otherwise if the web view behaves like a modern browser this would be awesome.
OK got you on WebGL. Makes sense to wait for that since you’re building this platform from the ground up.
It’s not a finalized plan - but we were thinking to expose a WebView control in UXP - This will offer you the possibility to host an actual webkit/chrome web view and run some code in it.
It will be slower and occupy more resources (that’s why we’re not doing it by default about this approach), but you would get full OS level support for a full browser.
Also you won’t have access to the host application API in the same way (you would have to create your own bridge like EvalScript used to do).
Kerry should know more,
Ah I see, that would actually solve the issues I’m concerned about! Implementing an interface layer to the host API would not be that big of a deal I guess since it works pretty well in CEP at the moment. Sounds promising for all the cases UXP won’t be enough. Thanks for the insights.
@markusbergelt to clarify, we aren’t currently exploring making webview widely available - this is due to security and performance reasons (one of the benefits of UXP is that it’s not spinning up a new chrome browser for each plugin running). The areas we are exploring are specifically for personal and enterprise use where the admin can take ownership of their internal security policies. We’ll continue exploring other options for augmenting UXP’s capabilities to support usecases like your own in UXP directly.
@afuchs I see… I’ll keep my eyes on UXP and will see how it evolves as it gets introduced to AE. Thanks for clarification
One option that might be worth exploring today would be using an actual browser for parts of the experience that require webgl with initialization/configuration happening inside the plugin, and communication between the two managed via an intermediary websocket server (UXP supports websocket clients today).
one could run it on the smartphone or a tablet